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ABSTRACT 



A diagnostic apparatus for testing devices such as com- 
puter systems, and computer system components such 
as disk drives or printers. The device comprises a main 
unit, the main unit having a central processing unit for 
executing instructions, issuing commands, and receiving 
data from a first device. The apparatus also has a first 
peripheral unit coupled to the main unit, the first pe- 
ripheral unit having ports for interfacing with the first 
device, the first peripheral unit being interchangeable 
with a second peripheral unit for interfacing with a 
second device. The apparatus also comprises a first 
non-volatile memory unit coupled to the main unit. The 
first non-volatile memory unit comprising a first set of 
tests for the first device, the first non-volatile memory 
unit being interchangeable with a second non-volatile 
memory unit comprising a second set of tests for a sec- 
ond device. These interchangeable parts are provided 
so that the user may test various types of hardware. The 
apparatus further comprises software means for provid- 
ing termination on a bus and methods for simulating 
devices on a bus for remote entry into diagnostic pro- 
grams. 

5 Claims, 17 Drawing Sheets 
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Figure 6a 
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Figure 9 - Diagnostic Tool Base Unit 
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Figure 10 ■ Peripheral Port Pack 
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Figure 11 
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Figure 12a 
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Figure 12c 
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Figure 12d 
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ACTIVE BUS TERMINATION DEVICE 

This is a divisional of application Ser. No. 
07/771,127, filed Oct. 3, 1991 now U.S. Pat. No. 5 
5,357,519. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to the field of diagnostic 10 
methods and apparatuses for computer systems. More 
specifically, this invention relates to a device and 
method for diagnosing a faulty computer system with- 
out disassembling the system. 

2. Description of Related Art 15 
The diagnosis of faulty computer systems, at times, 

can be a difficult process. For systems which are incapa- 
ble of powering up and performing a system bootstrap 
initialization process, determining which components 
are faulty requires substantial time and effort using a 20 
variety of methods. One method of diagnosing a faulty 
computer system is to remove components in the com- 
puter system one by one and replace them with compo- 
nents which are known to work. Such a "trial and er- 
ror" approach not only requires an on-hand inventory 25 
of components which are functional, but also requires 
that the computer system be disassembled. This type of 
diagnosis requires substantial effort to disassemble and 
reassemble the system and does not necessarily identify 
the underlying defect which caused the failure. 30 

Yet another method for diagnosing a faulty computer 
system is to couple various types of diagnostic appara- 
tuses to individual components. This process requires 
some disassembly of the computer system to attach 
diagnostic probes to the individual components. De- 35 
pending on the location of individual components, this 
process may take a lot of time to disassemble the faulty 
device. This also requires specialized tools to test indi- 
vidual components. 

For a system which is able to power up and execute 40 
a system bootstrap initialization but does not function 
properly, diagnosis may be performed using a software- 
utility. Some types of utility programs may diagnose 
certain faulty components, but if the faulty components 
are required to operate the utility, the diagnosis of the 45 
system will be impossible. Even though the disassembly 
of the computer system may not be required to run such 
a diagnostic program, this program may be limited by 
the inability to test certain hardware components. 

Some computer systems perform a software diagnos- 50 
tic self-test upon a system bootstrap initialization pro- 
cess. This type of routine tests various components in 
the system prior to operation to ensure that the system 
is operating properly. One such diagnostic routine is 
known as the "Test Manager" program which forms 55 
pan of the bootstrap initialization procedure of the 
Macintosh® brand computer available from Apple 
Computer, Inc. of Cupertino, Calif. (Macintosh ® is a 
trademark of Apple Computer, Inc.). This initialization 
process includes, among other things, initializing versa- 60 
tile interface adaptor (VIA) circuits, serial communica- 
tion controller (SCQ circuits, floppy, disk drive inte- 
grated circuit controllers, small computer system inter- 
face controller (SCSI) circuits, and sound device cir- 
cuits coupled to the system. These routines, which are 65 
embedded in read-only memory (ROM) contained 
within the system, require that the system be capable of 
activating system power and initializing. If the system 
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cannot be initialized, then certain types of tests may not 
be able to be performed. 

Another drawback of prior approaches to diagnosing 
computer systems is that different computer systems 
have a variety of interfaces and ports. Each port or 
interface requires a different connector and/or different 
circuitry to test these ports or' interfaces. For instance, 
in addition to generic serial and parallel ports such as 
RS-232 standard ports or SCSI ports, some computer 
systems may have manufacturer-specific ports such as 
the Apple Desktop Bus (ADB) brand interface manu- 
factured by Apple Computer, Inc. The wide variety of 
ports, interfaces and other coupling means for various 
systems makes it difficult to diagnose the many types of 
computer systems in the marketplace. Because the pa- 
rameters of each interface and/or port must be known 
to the individual diagnosing the computer system, it is 
difficult for one person to diagnose a variety of ma- 
chines. In addition, it is helpful if various types of con- 
nectors are available for coupling to the various systems 
for diagnosis. In summary, no single device possesses 
the necessary characteristics to diagnose various types 
of computer systems at all levels of operation. 

SUMMARY AND OBJECTS OF THE 
INVENTION 

One object of the present invention is to provide a 
device which can diagnose a computer system incapa- 
ble of performing a system power up or bootstrap ini- 
tialization process. 

Another object of the present invention is to provide 
a device which performs nonintrusive diagnostics of a 
computer system. 

Another object of the present invention is to provide 
a device which is capable of diagnosing various types of 
computer systems including system-specific connectors 
and interfaces. 

Another object of the present invention is to provide 
a method and apparatus which facilitates diagnostics of 
a computer system with a minimal level of system- 
specific knowledge by a user. 

These and other objects of the present invention are 
provided for by a diagnostic apparatus for testing de- 
vices such as computer systems, and computer system 
peripheral devices such as disk drives or printers. The 
apparatus comprises a main unit, the main unit having a 
central processing unit for executing instructions, issu- 
ing commands, and receiving data from a first device 
being tested. In a preferred embodiment, the apparatus 
comprises a display and keyboard for communicating 
with a user of the apparatus. The apparatus also has a 
first peripheral unit coupled to the main unit, the first 
peripheral unit having ports for interfacing with the 
first device, the first peripheral unit being interchange- 
able with a second peripheral unit for interfacing with a 
second device. The first peripheral unit may, for exam- 
ple, be used for testing one computer system such as a 
personal computer, and the second peripheral unit may 
be used for testing a second personal computer, disk 
drive, or printer. The apparatus also comprises a First 
non-volatile memory unit coupled to the main unit, the 
first non-volatile memory unit comprising a first set of 
tests for the first device. The first non-volatile memory 
unit is interchangeable with a second non-volatile mem- 
ory unit comprising a second set of tests for a second 
device. These units are provided so that the user may 
test various types of hardware. 
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These and other objects of the present invention are Configuration of the Diagnostic Tool 

provided for by a devjce for terminating a bus. In a 3 e ° 

preferred embodiment, the termination on a bus, for FIG. 1 shows the external physical configuration of 

example a small computer system interface (SCSI) may the preferred embodiment of the present invention, 

be desired. The device comprises a first means for acti- 5 Diagnostic device 100 is generally used for testing the 

vating termination of the bus which, in a preferred operation of computer systems, Jiowever, it may be used 

embodiment, is a flag in a register. When set, the flag for testing individual components of computer systems 

switches on SCSI termination, and when not set (e.g., such as hard disk drives, printers, monitors, or other 

cleared) there is no termination. The device further peripherals. Diagnostic device 100 comprises several 

comprises a second means coupled to the first means for 10 portions which are shown in their assembled and oper- 

supplying power, the second means being activated atin S configuration in FIG. 1. Diagnostic device 100 

upon activation of the first means. In a preferred em- comprises a display 110 for presenting information to 

bodiment, the second means is a p-channel MOS-FET. *e user of the device^Display 110 is one of the many 

The device also has a third means coupled to the second ^qpid crystal disp ays (LCD's) which are commercially 

means for limiting voltage received from the second 15 available and well-known to those skilled m the art 

means which is a low dropout voltage regulator. Lastly, Diagnostic device 100 further composes a keypad 120 

the device has a fourth means coupled to the third for indicatmg command selections and other infonna- 

means for limiting transient voltages on the bus, which tlon to , dev,ce 10 °: ^^^V^* * V 

prevents the bus from appearing as if any device is P ower h S ht enuttm S diode (LED) 130 indicating when 

couoled to the bus 20 battery power m the unit is becoming depleted. In order 

tS. to provide the utmost flexibility, device 100 comprises 

These and other objects of the present invention are | r, '.„,-„ i_- L n u 

J c .i . • j. modules 140, 150, and 160 which are all removable from 

provided for by a means for remotely entering a diag- ' .' , j , ,„n 

r . J . ^ __. , device 100 and interchangeable with other modules. 140 

nostic program in a computer system. This method , „„ , , , „ ... ., 

...... r- 1 j ■ i j . .v and 150 are removable ROM packs which provide 

comprises simulating a first device coupled to the com- ,._ . . . A ,- _ j V, .v. 

. y , . 6 . . , . , v _ . , 25 different tests and different operatmg modes for the 

puter system and simulating a dnver for the first device various ^ ^ Q * 6 uter 

coupled to the computer system The computer system (herdnafter ^ mdel test or tjut's) which may be 

is caused to load the dnver and then to call the dnver to taM b device m m fc ^ a removable module 

execute itself in the computer system. The dnver con- ^ fa 1agwn ^ a k „ p ort k m ides 

tains a jump mstmction to the diagnostic program caus- 3Q computer system ports for ^ various types of ^ 

mg the diagnostic program to then execute. which may ^ p]resent on a system being tested R0M 

BRIEF DESCRIPTION OF DRAWINGS packs 140 and 150 and port pack 160 will be discussed in 

more detail below. 

The present invention is illustrated by way of exam- FIG. 4 shows one side 400 of device 100. Side 400 of 
pie and not limitation in the figures of the accompany- 35 device 100 comprises a power switch 410 which is a 
mg in which like references indicate like elements and in single pole> single throw (SPST) rocker switch which is 
wn ' cn; used to activate power to device 100. Further, device 

FIGS. 1 through 7 including 6a, show the external 10 q comprises an adaptor plug 420 which is a miniature 
physical configuration of the diagnostic apparatus. dua] conduc tor plug used for supplying 5 volt power to 

FIG. 8 shows a removable port pack and removable 40 umt iqq v ; a an i n t egra ted power supply adaptor cable. 
ROM packs in a disassembled configuration used in the Diagnostic device 100 may also be powered by an inter- 
diagnostic device of the preferred embodiment. na i battery when not coupled to a power supply via 

FIG. 9 is a block diagram of the base unit of the p j ug 42 o. r n addition, as shown on side 400 of FIG. 4, 
diagnostic device. device 100 comprises a female serial port 430 which is 

FIG. 10 is a block diagram of file port pack of the 45 used f or coupling device 100 to a modem (modulator/- 
diagnostic device. . , demodulator) for communication over telephone lines. 

FIG. 11 is a schematic of the software controllable xhis provides the capability for device 100 to communi- 
SCSI termination apparatus used by the diagnostic de- catg with other devices 100 or UUT's which can be 
vice. remotely tested. Connector 430 is a mini 8-pin serial 

FIG. 12a-12d are flowcharts showing various ways 50 port connector which conforms to EIA standard RS- 
to enter test routines used in the diagnostic device of the 232 signal conventions. The signals and pins on connec- 
preferred embodiment. tor 430 are described in more detail in Guide to the 

FIGS. 13 through 15 show the SCSI device emula- Macintosh Family Hardware, Second Edition by Apple 
tion used by the preferred embodiment to enter the Test Computer, Inc. avaUable from Addison-Wesley Pub- 
Manager brand diagnostic program. 55 lishing Company, Inc. (copyright 1990) (hereinafter 

DETAILED DESCRIPTION "^7^ * **** ^ 

and detailed connections to port 430 will be discussed in 

A device and method for diagnosis of computer sys- more detail below. 

terns is described. In the following description, for the 

purposes of explanation, numerous specific details are 60 Removable ROM Packs 

set forth such as circuitry, signal names, signal lines, and For the greatest flexibility in testing various types of 
pan numbers are set forth in order to provide a thor- computer systems and other devices with diagnostic 
ough understanding of the invention. It will be obvious, tool 100, ROM packs 140 and 150 and port pack 160 are 
however, to one skilled in the an that the invention may provided which are all removable from main unit 190 of 
be practiced without these specific details. In other 65 device 100 as shown in FIG. 8. These packs may be 
instances, well-known circuits, structures, and tech- replaced with other packs which have different ports 
niques have not been shown in detail in order to not and/or different of tests. As is shown in FIG. 8, port 
unnecessarily obscure the present invention. pack 160 may be coupled to main unit 190 via connector 
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810. Connector 810, in the preferred embodiment, is a 
Fujitsu FCN215Q080:G/O, 80-pin. male connector. A 
detailed description of the signals and the lines on con- 
nector 810. will be discussed below. 810 provides an 
interface with main unit 190 of device 100 so that com- 5 
munication with various peripheral ports on pack 160 
may be accomplished. Port pack 160 may be coupled to 
main unit 190 by affixing 160 to 190 in the direction 
shown as 840 on FIG. 8. This mates connector 810 with i 0 
a corresponding female connector on main unit 190 (not 
shown). In addition, 100 comprises removable ROM 
packs 140 and ISO which comprise non-volatile test 
routines and other device or system-specific diagnostic 
programs. As is shown in FIG. 8, each module such as 15 
150 comprises a connector such as 820 which is mated 
to the main unit 190 to provide access to the test rou- 
tines embedded in the non-volatile memory of each 
ROM pack 140 or 150. Each ROM pack such as 140 and 
150 may be coupled to main unit 190 via a 40-pin Fujitsu 
FCN215Q040-G/O male connector which mates with a 
corresponding female connector on main unit 190 (not 
shown). A ROM pack such as 140 may be inserted into 
main unit 190 in a direction shown by arrow 850 in FIG. 25 
8 to provide communication between main unit 190 and 
ROM packs 140 and 150. 

Removable Port Pack 

A more detailed view of the rear 600 of port pack 160 30 
is shown in FIG. 6. 600 of 160 shows various ports 
contained in one port pack 160 which is designed for 
testing various models of the Macintosh brand com- 
puter system family manufactured by Apple Computer, 35 
Inc. of Cupertino, Calif. Port pack 160 is used for test- 
ing the models Macintosh SE, SE/30, and the Macin- 
tosh II brand family of computers including the IIx, 
Ilex, among others. It can be appreciated by one skilled 
in the an, however, that a port pack other than 160 may 40 
be plugged into base unit 190 of diagnostic device 100 in 
order to provide a different set of ports. In the preferred 
embodiment, port pack 160 has six ports. Base unit 190 
may accommodate any number of ports depending on 
the configuration of the port pack. It will be appreciated 45 
by one skilled in the art, that any number of ports may 
be present on a peripheral port pack in various embodi- 
ments of the present invention. A detailed description of 
the ports available on port pack 160 of device 100 50 
shown in FIG. 6 will now be discussed. 

As is shown in FIG. 6, side 600 of port pack 160 
comprises several ports which interface with Macintosh 
brand computer systems. Port pack 160 comprises two 
Apple Desktop Bus (ADB) brand connectors 610 and 55 
620, two miniature 8-pin EIA RS-424 standard serial 
connectors 630 and. 640, a two-conductor miniature 
audio connector 650 for coupling to audio ports, and a 
25-pin female DB25 SCSI connector 650 for coupling to 
devices such as SCSI disk drives and disk drive ports on 
computer systems. ADB ports 610 and 620 are used for 
coupling with ADB brand ports on Macintosh com- 
puter systems for communicating various information 
to and from the computer via devices such as key- $ 5 
boards, trackballs, or mice. The pin assignments for 611 
through 614 are shown in FIG. 6 and the corresponding 
signals are described with reference to Table 1 below. 
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TABLE 1 



Pin 


Signal 




Number 


Name 


Signal Description 


fill 


ADB 


Bidirectional data bus used for 






input and ostput. It is an open-collector 






signal pulled up to +5 V through a 






470 SI resistor on an Apple 






Macintosh brand computers main 






logic board. 


612 


POWER.ON 


On the Macintosh 11 family, a key 






on the keyboard momentarily grounds 






this pin to pin 614 to switch on the 






power supply. On other Apple 






Macintosh brand computers this 






pin is not connected. 


613 


+5 V 


+ 5 volts. 


614 


GND 


Ground. 



A more detailed discussion of the ADB signals and 
devices used in the preferred embodiment is discussed 
in Hardware Guide at pages 287-326. A more detailed 
discussion of signals issued by device 100 for perform- 
ing diagnostics of a computer system is discussed below. 
The pin assignments for connector 620 are the same as 
those used on connector 610. 610 are 620 are indicated 
by their corresponding labels 619 and shown in FIG. 6, 
the ADB icons. Further, each of the connectors has a 
key 615 associated with it such as shown with reference 
to 610, to prevent improper insertion of cables into 
connectors 610 or 620. 

Port pack 160 further comprises two serial ports 630 
and 640. Serial ports 630 and 640 are used for coupling 
to a printer port or a modem port on a system as indi- 
cated by the appropriate labels 639 or 649. As discussed 
above, each of the serial ports in the preferred embodi- 
ment and on port pack 160 conform to the EIA RS-422 
standard signal conventions which are described in 
more detail in Hardware Guide at pages 357-374. The 
pin assignments for serial port 640 is described with 
reference to Table 2 below. The signal assignments for 
the pins on 630 are the same. 

TABLE 2 



60 



Signal Assignments for Mini 8-pin Serial Port Connector 640 
Pin Signal 
Number Name Signal Description 

641 HSKo Handshake ouput. Driven inverted. 

Von = 3.6 V; Vol = -3.6 V; Rl = 450 C 

642 HSKi Handshake input or external clock. Received 

uninvened. 

Vih = 0.2 V; Vil = -0.2 V; Ri = 12K fl 

643 T X Transmit data (inverted). Driven inverted or 
D- 

tristated depending on the operation mode. 
Voh = 3.6 V; Vol = -3.6 V; Rl = 450 fl 

644 GND Signal ground. Connected to logic and chassis 

ground. 

645 R X Receive data (inverted). 
D- 

Vih = 0.2 V; Vil = -0.2 V; Ri = 12K n 

646 T X Transmit data. Driven uninvened or instated 
D + 

depending on the operation mode. 

Voh » 3.6 V; Vol = -3.6 V; Rl = 450 £1 

647 GPi General-purpose input. 

Vih = 0.2 V; Vil = -0.2 V; Ri = 12K 41 

648 R x Receive data. Received uninverted. 
D + 

Vih = 0.2 V; Vil = -0.2 V; Ri = 12K n 



The two remaining ports on port pack 160 of the 
preferred embodiment are shown as 650 and 660 in FIG. 
6. 650 is a standard 2-conductor female monaural audio 
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miniature jack used for diagnosing the sound capabili- 
ties of the device being tested. This is indicated by the 
sound label icon 659 above the sound jack. The process- 
ing of the signals received from sound jack 650 is dis- 
cussed below. 

Lastly, 160 comprises SCSI connector 660 which is a 
standard 25-pin female DB25 SCSI connector which is 
discussed in more detail in Hardware Guide at pages 
375-396. SCSI connector 660 is labelled by icon 669 as 
shown in FIG. 6. The circuitry coupled in main unit 190 
to port pack 160 and thus to connector 660 is the dis- 
cussed in more detail below. Pin outs on connector 660 
are assigned as shown in FIG. 6a with reference to 
Table 3 below. 

TABLE 3 



Pin 



Signal Assignments for SCSI Connector 660 
Signal 



Number 


Name 


Signal Description 


661 


/REQ 


Request for a REQ/ ACK data transfer 






handshake 


662 


/MSG 


Indicates the message phase 


663 


/I/O 


Controls the direction of data movement 


664 


/RST 


SCSI data bus reset 


665 


/ACK 


Acknowledge for a REQ/ACK data transfer 






handshake 


666 


/BSY 


Indicates whether SCSI data bus is busy 


667 


GND 


Ground 


668 


/DB0 


Bit 0 of SCSI data bus 


669 


GND 


Ground 


670 


/DB3 


Bit 3 of SCSI data bus 


671 


/DB5 


Bit 5 of SCSI data bus 


672 


/DB6 


Bit 6 of SCSI data bus 


673 


/DB7 


Bit 7 of SCSI data bus 


674 


GND 


Ground 


675 


/C/D 


Indicates whether control or data is on 






the SCSI bus 


676 


GND 


Ground 


677 


/ATN 


Indicates an attention condition 


679 


/SEL 


Selects a target or an initiator 


6S0 


/DBP 


Parity bit for SCSI data bus 


681 


/DB1 


Bit 1 of SCSI data bus 


682 


/DB2 


Bit 2 of SCSI data bus 


683 


/DB4 


Bit 4 of SCSI data bus 


684 


GND 


Ground 


685 


TPWR 


+ 5 volts terminator power 



10 



15 



20 



25 



30 



35 



40 



Circuitry of the Diagnostic Tool 

A block diagram of the main unit of diagnostic appa- 
ratus 190 is shown with reference to FIG. 9. Central 45 
processing unit 901 of diagnostic tool 100 is a 
68HC1 1E9 microcontroller manufactured by Motorola, 
Inc. of Schaumburg, 111. The HC11E9 version of the 
microcontroller comprises the following features which 
are useful for implementing certain features of the pre- 50 
ferred embodiment: 

12 kilobytes of internal programmable read-only 
memory (PROM); 

512 bytes of internal read-only memory (RAM); 

512 bytes of internal electrically erasable programma- 55 
ble read-only memory (EEPROM); 

a serial communication interface with 32 selectable 
baud rates; 

a serial peripheral interface; 

an 8-channel, 8-bit analog to digital (A/D) converter; 60 
and 

an 8-bit pulse accumulator/generator system. 
A detailed description of the M68HCUE9 CPU 901 
used in the preferred embodiment may be found in the 
publication M68HC11 Reference Manual, Revision 1, 65 
by Motorola, Inc. of Schaumburg, 111. (1990). CPU 901 
is docked by a 9.8304 MHz crystal which internally 
divides to a 2.45676 MHz "machine cycle" timing refer- 



ence for CPU 901 and external devices. CPU 901 is set 
into a "special bootstap" mode for updating and testing 
its internal EEPROM. During the normal operation of 
the preferred embodiment, CPU 901 is run in its ex- 
panded multiplex mode wherein dedicated ports B and 
C on CPU 901 are converted to. 16-bit multiplex address 
and 8-bit data lines ADO through A/D7 and A8 
through A15. 

In addition to the onboard non-volatile memory and 
RAM available to CPU 901, diagnostic base unit 190 
further comprises a 32-kilobit by 8-bit static random 
access memory (SRAM) 902 which is coupled to CPU 
901. Memory 902, in a preferred embodiment is a 32- 
kilobit by 8-bit SRAM, pan No. 60L256 manufactured 
by Motorola, Inc. of Schaumburg, 111. SRAM 902 is for 
storing additional information needed by CPU 901, 
such as a buffer area for various ports and for use as a 
scratch pad memory. As is shown in FIG. 9, pulse accu- 
mulator circuitry of CPU 901 is coupled to port pack 
connector 910 via port A 901a to provide communica- 
tion with various circuitry contained in the peripheral 
port pack 160 as shown in FIG. 8 via connector 810. 
Port A 901a doubles as the pulse accumulator/timer 
circuit and I/O lines for CPU 901. These lines provide 
the input capture and output capture compare functions 
for time signal measurements and generation to and 
from base unit 190. Port A 901a is used for handling the 
UUT's input/output (I/O) signals. PAL's 980 provide 
the necessary address decoding to. access SRAM 902. 

Further, port E 901e of CPU 901 is coupled to con- 
nector 910 which is used as an analog to digital (A/D) 
port. Port E 901e is used for measuring various voltages 
from the UUT including the battery and the power 
supply on the UUT. These are measured via channels 1, 
2, 3, 4, and 5 of the A/D converter internal to CPU 901 
coupled to port E 901e. Certain input signals are fed 
through voltage divider circuits and then through high 
impedance op amps. The divider and op amp circuit are 
used to measure voltages up to twice the + 5 volt refer- 
ence provided at VRjysuch as for the sound connections 
and certain serial port lines. This increases the gain of 
certain input signals prior to digitizing by CPU 901. The 
low voltage reference ~Vlh for the A/D converter is 
tied to ground. 

Address/data lines 901c of CPU 901 are coupled to 
two port replacement units 920 and 930 which, in the 
CPU 901's expanded mode, allow additional ports to be 
made available to CPU 901. When operating CPU 901 
in the expanded mode ports B and C of the 68HC11 
processor are reconfigured to operate as multiplexed 
address/data lines A/DO through A/D7 and A8 
through A15. Of course, it will be appreciated by one 
skilled in the art, that other microcontrollers which do 
not operate in this manner may not need port replace- 
ment units such as 920 and 930. Port replacement unit A 
920 is used for controlling keypad 120 and LCD display 
110 of diagnostic base unit 190. Address/data lines of 
port 901c are further coupled to a second pot replace- 
ment unit 930. 930 is coupled to a SCSI interface 940 
which is a standard 53C80 SCSI interface integrated 
circuit manufactured by NCR Corporation for provid- 
ing SCSI transfers to and from port pack 160 as shown 
in FIG. 1. 

Address/data lines 903 of CPU 901 are also coupled 
to ROM pack connectors 950 and 960 which are stan- 
dard 40-pin CN215J040-G/O female connectors manu- 
factured by Fujitsu Corporation. These provide the 
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coupling between the ROM packs 140 and ISO and interrupt line of CPU 901 to indicate the issuance of a 
CPU 901 for hardware specific diagnostics. Communi- command. 

cation with ROM packs 140 and 150 is provided via A second port replacement unit B 930 shown in FIG. 
port replacement unit B 930 and PAL's 970. PAL's 970 9 is used for providing communication with ROM 
are also coupled to remote port 430 for serial communi- 5 packs 140 and 150, and port pack 160 in the preferred 
cations to perform remote diagnosis of peripherals or embodiment. When port replacement B 930 is selected 
computers over telephone lines via modem. via the chip select signal, it is -used for communicating 

When CPU 901 is operated in its multiplexed or ex- with SCSI interface 940, and ROM packs 140 and 150. 
panded mode, general purpose I/O ports B and C of It is also used for providing control to a UUT serial port 
CPU 901 configured to operate as multiplexed address- 10 901d and for communication over remote port 430. It 
/data lines. Port replacement unit A 920 is coupled to can be appreciated by one skilled in the art, however, 
the address/data multiplex lines of port 901c on CPU that any number of computer systems and/or ports may 
901 in order to provide communication between keypad be used depending on the configuration of the port 
120, LCD display 110 and unit 190. Address lines A8 pack, such as 160, which is coupled to diagnostic base 
through All are processed through a PAL to provide 15 unit 190. Port C 930c of port replacement unit B 930 
the necessary decoding to generate a chip select signal provides communication with SCSI controller 940, 
(/CS) in order to indicate which of the two port re- which is, in turn, coupled to port pack 160 via connec- 
placement units is being accessed. Port replacement unit tor 910. This provides communication with SCSI de- 
920 enables communication between keypad 120, LCD vices coupled to a port such as 660 shown in FIG. 6. 
display 110, and CPU 901. Port B 920i of port replace- 20 Port C 930c of port replacement unit B 930 acts as a 
ment unit 920 is used for communication with LCD bidirectional interface to controller chip 940, but also 
display 110, except for 3 bits of port B which are used provides a serial communications port selector line for 
for controlling various functions in port pack 160. The communication with remote port 430. In addition, a 
4 most significant bits of the control information passed sleep select pin (/TIRED) is coupled to port C which is 
through port 6 aTe used for controlling display 110. In 25 used for putting diagnostic apparatus 100 into a mode in 
the preferred embodiment, display 110 is an which the minimum power is consumed (known as a 
LM2433A4C16B dot matrix 4 line by 16 character liq- "sleep" mode). Power consumption is minimized by 
uid crystal display module available from Densitron deactivating the display, and stopping execution of all 
International Corporation. Display 110 requires eight functions except monitoring keyboard interrupts in a 
bits of information to generate a character. 4 bits (a 30 manner well-known to those skilled in the art. SCSI 
nibble) of each datum contained in the control register data is memory mapped into RAM area 902 providing 
of port B is written individually to the memory mapped bidirectional data transfers between port replacement 
region for LCD display 110 at a time. The high order unit B 930 and SCSI communications chip 940 for read- 
nibble data is first sent for the display, followed by the ing and writing data between UUT's. Signals for con- 
low order nibble data in sequential order. When LCD 35 trolling SCSI transfers between communications chip 
display 110 receives the high nibble of an instruction or 940 and port replacement unit 930 are well-known to 
display character, it latches the data until it receives the those skilled in the art and are used for SCSI transfers 
low order nibble data and then the data (character or via 940 in the preferred embodiment. One function 
instruction) becomes available for display. provided by the preferred embodiment is the use of a 

The remaining four bits of the port B control register 40 software-controllable SCSI termination of the UUT for 
920i of port replacement unit A 920 are used for various simulating the presence of device(s) coupled to the 
control functions. Bit 0 (the least significant bit) of port UUT. This termination is activated by setting a bit in a 
B 920b is used to control the command/display mode control register of port B. Diagnostic base unit 190 can 
for LCD display 110. Bit 1 is used to control the read also simulate a SCSI device to a UUT by simulating the 
and write direction of LCD display 110. The two re- 45 presence of partitions, and file allocation tables for per- 
maining bits of port B 920A are used for controlling the forming other types of testing. 

UUT. Bit 2 is used to initiate a "power on" sequence in Port B 9306 of port replacement unit B 930 is used as 
the Macintosh II brand family of computers available general purpose port for external ROM and RAM page 
from Apple Computer, Inc. of Cupertino, Calif, via port control, as well as ROM pack and serial EEPROM 
pack unit 160 as discussed with reference to Table 1 50 selectors. Address lines A12 through A15 on port 901c 
above. Bit 3 of port B 9206 of port replacement unit A of CPU 901 are remapped using PAL's 970 to provide 
920 is used to supply power to port pack connector 910 the appropriate memory mapping in CPU 901's random 
during data transfers as a means of prolonging the bat- access memory. Each individual ROM pack is selected 
tery life of diagnostic tool 100. via a select bit contained within the control register for 

Port C 920c of port replacement unit A 920 is used for 55 the ROM packs. This selects which connector 950 or 
receiving information from keypad 120. Keypad 120, in 960 is accessed for data, to access tests to residing in 
one embodiment, is a 1 5-key 9-pin custom silicon rubber ROM pack 140 or ROM pack 150. Each ROM pack 
keypad. 120 may be one of any number of keypads such as 140 or 150 may individually contain hardware 
which are commercially available. The five most signif- specific tests. 

icant bits of the keypad memory map register are used 60 Diagnostic base unit 190 lastly comprises a serial 
for receiving data from keypad 120 in a manner well- communication port which is coupled to port D 90ld of 
known by those skilled in the an. The three least signifi- CPU 901. Three separate serial communication lines are 
cant bits of the control register are used for enabling- provided through port 90W which are activated by two 
/disabling the columns on the keypad for receiving data lines on port B 930£> of port replacement unit 930. When 
input from keypad 120. Key 921 on keypad 120 (the "*" 65 both of the control bits axe cleared, the serial communi- 
or "command" key) is used for generating an interrupt cations port 901d is put into a loop back test mode, 
request to CPU 901 that a coined is being issued Either one of these signals being activated enables one 
through keypad" 120. This is coupled to the maskable of two sets of serial communication transmit and re- 
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ceive lines. Both bits being set enables a third set of having such a desion, the user must activate power 

transmit and receive lines. Port D 901a" of CPU 901 is manually. 

coupled through an RS-232 driver receiver chip (Mo- For sampling various voltage levels on connectors 

torola part No. MCI 45407 — not shown) which is then 610 and 620 coupled to the UUT, pins 611 and 614 are 

coupled to port pack connector 910. The third set of 5 coupled through analog multiplexers 1030 to connector 

serial transmit and receive lines are used for communi- 810. In addition, for communicating with the UUT, 

cation over remote port 430 for remote UUT testing. connectors 610 and 620 are coupled to lines 1070 and 

The first set of transmit and receive lines are the pri- then to connector 810. Communication is thereby pro- 

mary communication means by which the preferred vided between the UUT via connectors 610 and 620 and 

embodiment communicates with software diagnostics 10 diagnostic base unit 190 for performing various tasks, 

embedded in certain types of computer systems, such as Communication via ports 610 and 620 is described in 

the Macintosh brand family of computers. These em- more detail witn reference to Hardware Guide at pages 

bedded software diagnostics are collectively known as 287-326. 

the "Test Manager." The second set of transmit and Serai and SCSI communication is performed with 

receive lines are used for the loop back communication 15 the UU" 1 through connectors 630, 640, and 660 is ac- 

port signals for serial printer ports used in the Macin- complished via the remaining lines 1070 coupled to 

tosh SE and Macintosh II brand family of personal connector 810. Sampling of voltages on these connec- 

computers tors ' s a ^ so P rov 'ded in a similar manner as discussed 

Standard RS-232 signals are used by diagnostic de- f e f^ t0 connectors 610 and 620 via analog 

vice 190 for communication with UUT's. However, 20 MUX s 1030 across lines 1040. Sound capabilities of the 

computer systems such as the Macintosh family of per- "? certam s y stems ' ma y also be ,' ested m 

sonal computers are capable of using EIA RS-422 hard- ner °*j\ r an ? log VOltai f' 35 "f > be a PP reclated °V 

ware protocols which are currently unused by the com- one skllled m ±e m& * be sam P led m sunUar manners - 

munications ports directly. The unused lines of the 2J Software Contollable SCSI Bus Termination 

RS-422 lines are selectively sampled using the A/D . ... - ~ ,. ,, , , 

... . _ . ,, n T. , *f. , . A detailed description of the software controllable 

mulnpfcxers on port pack 160 which, as discussed in scs] taa ^ aa c £ cuit mo of ^ ferred em . 

™? oni J' "t COnneCted *"f f D bodiment will now be discussed with reference to FIG. 

CPU 901 v.a port pack connector MA detailed de- n ^ , mes M ftQm amaectoI 810 to SCSI con . 

scnpaon of one peripheral port pack 160 which maybe 3Q nector ^ m lM throu ^ 101Q for ovidin the 

coupled to diagnostic base unit 190 m one embodiment bus tennination . Five volts ^ received on line 1121 {lom 

will now be discussed m more detail with reference to pin m Qn connector 660 t0 circuitry l010 Qne signal 

FIG - 10 - line, REG3 1060 from base unit 190, is provided which 

Circuitry of the Port Pack activates tennination. The remaining SCSI lines 1100 

35 from connector 660 are coupled to the 1 10 ohm resistors 

A block diagram of peripheral port pack 160 which 0 f res istor packs 1110, and resistor pack 1110 is coupled 
may be used m one embodiment of the present invention to ^ cathode on diodes in either of diode packs 1111, 
is shown and discussed with reference to FIG. 10. As 1112> or 1113. The anodes of all the diodes in diode 
was discussed with reference to FIG. 6 above, port nll m2 1113 are tied together and con- 
pack 160 comprises a series of ports 610 through 660 40 nectcd t0 ^ output line m4 of the low drop out posi . 
which are coupled via connector 810 to diagnostic base tive adjustable voltage regulator 1115. Voltage from 
unit 190 in order to test specific types of UUT's. Periph- m7 is fixed by rectors xm (121ft) and 1123 (249ft) 
eral port pack 160 has an FCN215Q080-G/O 80-pin wnich xe couple t0 ground on 1128 on 1115 and the 
male connector 810 manufactured by Fujitsu, Inc. output 1114 through a series of capacitors (1126 and 
which mates with connector 910 on base unit 190. A 45 1172 and 1124) tied to ground 1125. The input 1116 of 
control register of CPU 901 is used to select, via analog dev j ce 1U 5 j s coupled to the drain 1118 of a dual P- 
multiplexer 1030 shown in FIG. 10, analog signal chan- channel enhancement MOS-FET 1117. The source 
nels for measurement. Analog multiplexers 1030 ire mo Q f 1117 is coupled to the, termination power line 
controlled via analog line selectors 1050 which are H21 (which carries +5 volts) of the UUT (pin 685 on 
coupled to port A 901a of CPU 901. Another signal line 50 connector 660). Gate 1119 of MOS-FET 1117 is cou- 
coupled to port A 901a on CPU 901 is used for enabling p i e d to signal line 1060 coupled to a register in base unit 
SCSI termination. This is coupled via line 1060 from 190 received from for activating SCSI bus tennination. 
connector 810 to termination circuitry 1010. When this bit is set to a logic 0, a negative voltage is 

In the preferred embodiment, analog multiplexers created at gate 1119 of 1117 effectively sourcing +5 

1030 comprise four 74HC4051's available from Motor- 55 volts from pin 685 (tennination power) to 1116 on 1115. 

ola, Inc. The selection of each analog MUX 1030 ena- 1115 steps down the voltage to 3.8 volts which is sup- 

bles any or all of lines 1040 for conversion and measure- plied to diode packs 1111, 1112, and 1113. Diode packs 

ment of voltage values by base unit 190. Also, SCSI and nil, 1112, and 1113 drop the voltage down another 

serial data lines 1070 from port pack 160 are coupled to one volt to provide 2.8 volts to resistor pack 1110. The 

connector 810 for communication with the serial and 60 2.8 volts with 250 mA limiting resistors is provided to 

SCSI circuitry within base unit 190. An additional fea- the remaining SCSI lines 1100 and meets the proper 

hire provided by port pack 160 is UTON select line voltage and current specifications for SCSI tennination 

1021. When activated, this line activates power to cer- of the bus. 

tain types of UUT's. UTON select line 1021 is coupled On the other hand, when a logic "1" is present on 

to circuitry 1020 to momentarily ground pins 612 and 65 signal line 1060, the voltage at gate 1119 of 1117 is 

614 on connectors 610 and 620 in order to initiate- a equalized, and thus removing SCSI bus termination 

remote power up of the UUT as discussed with refer- from SCSI signal lines 1100. No voltage is provided 

ence to Table 1' above. For other types of UUT's not from drain 1118 of device 1117 to 1116. Each of the 
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resistors in resistor pack 1110 appears as an individual 
open circuit to SCSI connector 660. SCSI termination is 
thus effectively removed. In summary, an active signal 
over line 1060 causes 1010 to deactivate SCSI bus termi- 
nation on lines 1100, and a logic 0 received over line 5 
1060 causes 1010 to activate SCSI bus termination on 
lines 1100. 

Testing UUTs 

The testing of UUTs coupled to diagnostic tool 100 10 
via port pack 160 in the preferred embodiment is ac- 
complished via a sequence of routines embedded in 
ROM packs 140 and 150 which perform certain tests 
embedded in those ROM packs, or causes accesses to 
built-in diagnostics contained within the UUT. In the 15 
Macintosh family of personal computers, a series of 
routines known as the "Test Manager" is available in 
the system ROM of each computer. On a system which 
is not even able to power up and complete bootstrap 
initialization, this program will be unavailable. There- 20 
fore, certain "lowlevel" tests perform certain basic di- 
agnostics such as testing a "power on" battery on the 
motherboard, testing voltage levels on certain signal 
lines, determining whether there is SCSI termination, or 
measuring the voltage of SCSI termination. A summary 25 
of these tests is set forth below. Each of these low level 
tests is written in 68HC11 assembly language for CPU 
901 in the preferred embodiment but may be written in 
high level languages such as the "C" or Pascal pro- 
gramming language in alternative embodiments. These 30 
tests are perforated without entry into the diagnostic 
program by measuring voltages available on the various 
connectors, etc. which are coupled to tool 100 and a 
UUT. These tests are as follows: 

Tests that Do Not Require the Test Manager to 35 
Function 

Power Supply (PowrS) — This test measures the volt- 
age at the power supply of the UUT. The value can 
range from 0.0 volts to 5.5 volts. This test runs on 40 
UUTs in the Macintosh brand of personal computers. 
This test has no pass/fail. It displays the voltage with a 
message stating what range of values indicates a func- 
tional power supply (usually >4.5 volts). This test re- 
quires a cable to be connected to a UUT and either port 45 
610 or 620. 

Battery Voltage (Batt) — This test measure the bat- 
tery voltage off the ADB cable. The value can range 
from 0.0 volts to 10.0 volts. This test runs on Macintosh 
II motherboard and Ibc brand computers. This test has 50 
no pass/fail. It displays the voltage of the battery with 
a message stating what range values indicates a func- 
tional power supply (usually >6.5 volts). This test re- 
quires a cable to be connected from a UUT to either 
port 610 or 620. 55 

Power Up Voltage (PwUpV) — The Macintosh Ilex 
brand computer uses a trickle current from the power 
supply to provide power up voltage (which is provided 
by a battery on the motherboard). This test measures 
the trickle current off a cable coupled to 610 or 620. The 60 
value can range from 0.0 volts to 10.0 volts. It is very 
similar to battery voltage. This test has not pass/fail. It 
displays the voltage with a message stating what range 
of values indicates a functional power supply (usually 
>4.5 volts). This test requires a cable to be coupled to 65 
a UUT and either port 610 or 620. 

Power On CPU — This function, by imitating the 
action of pressing the soft power on key activates 



power in the UUT. This function runs on Macintosh II, 
IIx and Ilex brand personal computers. This function 
has no pass/fail. This test requires one cable to be con- 
nected from a UUT to port 610 or 620. 

SCSI Termination Check— This test checks the SCSI 
lines to see if a good termination exists on the bus. This 
test runs on all Macintosh brand personal computers. 
This test has pass/fail only. This test requires a SCSI 
cable to be connected from port 660 to the UUT. 

SCSI Termination Power — This test measures the 
termination voltage off the SCSI bus. The value can 
range from 0.0 volts to 5.0 volts. This test runs on all 
members of the Macintosh brand personal computer 
family although may also run on other computers hav- 
ing a SCSI connector similar to 600. This test has no 
pass/fail. It displays the termination voltage with a 
message stating what range of values indicates a func- 
tional terminator (usually >4.5 volts). This test requires 
a SCSI cable to be connected from connector 660 to the 
UUT. 

Termination [On/Off] — This function turns on (or off 
depending on the previous state) the internal termina- 
tion power of the SCSI bus in diagnostic tool 100. This 
function runs on all members of the Macintosh brand 
personal computer family. This function has no pass- 
/fail. It displays the termination condition as on or off 
on the screen. This function requires the SCSI cable to 
be connected to connector 660 and the UUT. 

SCSI Reset— This function forces a hard SCSI reset 
on the bus. This function runs on all SCSI type hard 
drives. This function has no pass/fail. This function 
requires a SCSI cable to be connected to connector 660 
and the drive. 

SCSI Bus Scan — This test scans the SCSI bus looking 
for hard drives. It builds a table of any drives it finds 
and allows the user to obtain information about each 
drive such as drive type manufacturer and size. This test 
runs on all SCSI type hard drives. This test has no 
pass/fail. This test requires the SCSI cable to be con- 
nected to connector 660 and the SCSI bus being tested. 

Test Manager Entry ("TstMd") — This function en- 
ters the Test Manager on the UUT. It cycles power and 
uses the SCSI bus to jump into the Test Manager on the 
UUT. This function runs on all machines equipped with 
a SCSI chip and having a Test Manager diagnostic 
program. This function fails only if it is not successful in 
entering the Test Manager. This function requires that 
cables be connected from the UUT to 660, 610 or 620, 
and a serial cable for the modem to be connected to port 
630 or 640. The process of entering the Test Manager is 
discussed in more detail with reference to FIGS. 12a 
through 12d. 

Entering the Test Manager Diagnostic System 

If the system is able to receive system power, how- 
ever, the Test Manager diagnostic program may be 
entered in the UUT to perform certain tests at the user's 
choosing using diagnostic tool 100. There are two ways 
in which the Test Manager is entered in a Macintosh 
brand personal computer using the preferred embodi- 
ment: by manually initiating a "non-maskable interrupt" 
(NMI) switch 620 on a Macintosh brand personal com- 
puter; or by causing the UUT to enter the Test Manager 
by simulating a SCSI device such as a disk drive and 
jumping to the Test Manager. The former option is 
difficult because the NMI switch must be issued within 
five to ten seconds after the UUT commences a bootup. 
Fairly tight timing constraints must be adhered to in 
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order to enter the Test Manager in this manner. In step 1228 shown in FIG. I2d, and process 1200 is re- 

UUT's which are able to initiate system power and turned from at step 1235. If, however, this is not the 

perform bootstrap initialization from an attached SCSI second attempt to terminate the SCSI bus, then step 

device, the latter method to enter the Test Manager is 1213 proceeds to step 1215 wherein the user is 

preferred. This is discussed in more detail with refer- 5 prompted with the message that "SCSI termination is 

ence to FIGS. 12 through 15. missing," and the user is givenjthe option to either "1) 

FIGS. 12a through 12d show one process 1200 which Terminate the bus or 2) cancel"-the present operation. It 

checks certain basic conditions in the UUT and at- is determined at step 1216 which option the user se- 

tempts to enter the Test Manager. Prior to bootstrap lected. If "cancel" is selected, step 1216 proceeds to step 

initialization from the simulated SCSI device provided 10 1235 on FIG. 12d and process 1200 is returned from. If, 

by device 100, certain basic conditions need to be estab- however, the "cancel" selection was not made, as deter- 

lished and tested for. Various corrective measures are mined at step 1216, then SCSI termination is attempted 

taken to try to enter the Test Manager if entry is not to be activated at step 1217 as shown in FIG. 126. SCSI 

successful on the first attempt. This process is shown in termination is performed, in the manner as discussed 

FIGS. 12a through 12a". When a UUT is connected to 15 earlier, using soft SCSI termination circuitry 1010 as 

tool 100 for performing diagnostics, process 1200 is shown in FIG. 11. Then, the message "Waiting for 

executed by tool 100 in order to attempt to enter the SCSI block read" is displayed at step 1218, wherein tool 

Test Manager. Process 1200 starts at step 1201, as 100 waits until the UUT attempts to read from the simu- 

shown in FIG. 12a, by displaying to the user at step lated SCSI device over port 660. Tool 100 will cause 

1202 that power-up routine is being initiated in the 20 the UUT to enter the Test Manager by "feeding" blocks 

UUT. At step 1203, the SCSI bus termination and boot to the UUT at step 1219. This is discussed in more detail 

attempt counters, which are used for multiple attempts with reference to FIG. 13. Tool 100 then waits three 

to terminate the SCSI bus or attempt to initialize the seconds in order for the Test Manager to be entered at 

system, are cleared. The serial modem port 430 on tool step 1220 after the issuance of the entry sequence at step 

100 is initialized at step 1204 in order to prepare the unit 25 1219. It is determined at step 1221, whether the UUT is 

for communication with a UUT. At step 1205, it is in the Test Manager. If the UUT is not in the Test 

determined whether the UUT is already powered up. If Manager, then process 1200 proceeds to step 1222 in 

power is present in the UUT, then process 1200 pro- FIG. 12c. If, however, the UUT was in the Test Man- 

ceeds to step 1221 as shown in FIG. 126. It is deter- ager, then process 1200 proceeds to step 1224 in FIG. 

mined whether the UUT is powered up, in a Macintosh 30 12t£ 

brand computer system, using techniques well-known As shown in FIG. 12t, process 1200 continues at step 

to those skilled in the art by sampling certain lines cou- 1222 wherein it is determined whether UUT power was 

pled to either ports 610 or 620 of peripheral port pack on already, or whether the power-on sequence at step 

160. If the UUT is not powered up, as determined at 1206 had to be performed. If power was already on in 

step 1205, then process 1200 proceeds to step 1206 35 the UUT, then process 1200 proceeds to step 1229 

wherein a power-up is attempted on the UUT using the wherein it is ascertained whether this is the second 

sequence issued over port 610 or 620 on port pack 160 attempt to boot the Test Manager in the UUT. If it is the 

for certain models of the Macintosh brand computer. second attempt to boot, then the message "SCSI/serial 

Again, it is determined at step 1207 whether the UUT problem. Try manual entry (press BACK)" is displayed 

has system power, and if it does, then process 1200 40 at step 1223. If process 1200 activated power in the 

proceeds to step 1212 on FIG. 126. If not, as determined UUT, then step 1222 also proceeds to step 1223 to dis- 

at step 1207, the message "Waiting for power on" is play the message. After the message if step 1223 is dis- 

displayed at step 1208, and process 1200 in FIG. 12a played, the exit process at step 1228 shown in FIG. 12a" 

proceeds. It is then determined, at step 1209, whether is performed, and process 1200 is returned from at step 

the "Back" key has been depressed by the user. This key 45 1235. If this is not the second boot attempt as deter- 

allows the user to abort from any process currently mined at step 1229, then the message "Waiting for 

executing in tool 100. This is used if the user wishes to power off' is displayed at step 1230, and the UUT is 

escape out of the waiting for power on loop of steps. checked via ports 610 and 620 to see whether power is 

1209 and 1210. If the "back" key is depressed, then off in the UUT at step 1231. If it is not, and the "back" 

process 1200 returns from Test Manager entry sequence 50 key was not depressed (causing interruption of process 

1200 at step 1211. If the "back" key has not been de- 1200), then steps 1231 and 1232 are performed repeti- 

pressed as determined at step 1209, then the UUT is tively until it is determined at step 1231 that power is off 

tested again at step 1210 to determine whether system in the system, or the "back" key is depressed. When 

power is present. Steps 1209 and 1210 are repetitively power-off is detected in the UUT at step 1231, then 

performed until it is detected that the UUT has pow- 55 process 1200 proceeds back to step 1206 to issue a 

ered up as determined at step 1210. Once power is pres- "Power-on" signal to the UUT as shown in FIG. 12a. If 

ent, step 1210 proceeds to step 1212 in FIG. 126. the "back" key is depressed, as determined at step 1232 

As shown in FIG. 12b, process 1200 continues at step (interrupting Test Manager Entry Process 1200), then 

1212 wherein it is determined whether SCSI bus termi- process 120)is returned from at step 1235 shown in FIG. 

nation is present in the UUT. If SCSI bus termination is 60 12c£ 

present, then 1212 branches to step 1218 to continue the If the UUT was not in the Test Manager as deter- 
initialization. If SCSI bus termination is not present, mined at step 1221 in FIG. 126, then process 1200 pro- 
then process 1200 proceeds to step 1213. 1213 deter- ceeds to step 1224 in FIG. 12d. Step 1224 in FIG. 12a" 
mines whether this is the second attempt to terminate checks the UXTTs tinting. This is determined using 
the SCSI bus, and if it is, step 1213 proceeds to step 1214 65 techniques well-known to those skilled in the art by 
wherein the message "Cannot terminate SCSI (cable sampling various signals received over the ports on port 
problem?), Try manual power on" is displayed to the pack connector 160 to see if the UUT is responding 
user. Then, process 1200 branches to the exit process at within defined tolerances. If the riming is bad as deter- 
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mined at step 1225, then process 1200 proceeds to step 
1226. If the timing is not bad as determined at step 1225, 
then the message "Communications established: CPU is 
in Test Manager mode" is displayed at step 1233, and 
tool 100 waits an additional five seconds for a user S 
intervening keypress, at step 1234. If no keypress is 
received, process 1200 returns at step 1235. If, however, 
the timing was bad as determined at step 1225, then 
process 1200 proceeds to 1226 to determine whether 
tool 100 activated power in the XJUT. If power was on 10 
already (tool 100 didn't activate the power), then a 
"RESET" command is issued to the UUT at step 1236 
and process 1200 continues at step 1221 as shown in 
FIG. 126. If power was activated in the UUT by tool 
100, then the message "Test Manager OK but timing 15 
problem found" is displayed at step 1227, and the exit 
process is branched to at step 1228. Then, process 1200 
is returned from at step 1235. 

Thus, at the end of process 1200, the UUT should be 
in its Test Manager mode, or the user is prompted with 20 
various options that he may take in order to perform 
diagnostics on the UUT. The entry into the Test Man- 
ager by simulating a SCSI device mentioned with refer- 
ence to step 1219 will now be discussed. 

25 

Entry Into the Test Manager by Simulating a SCSI 
Device 

Entry into the Test Manager is performed by diag- 
nostic tool 100 by simulating a SCSI device to the UUT. 
This is accomplished by sensing signals received 30 
through connector 660 transmitted by the UUT. When 
the appropriate SCSI initialization signals are received 
through port pack 160 from a UUT coupled to connec- 
tor 660, diagnostic tool 100 issues response signals 
through connector 660 to the UUT to cause the system 35 
to jump to the Test Manager. It performs this by simu- 
lating a SCSI device such as a disk drive using a driver 
descriptor map (DDM) and partition map entry which 
is expected by certain UUT's using SCSI devices. These 
entries are shown in more detail in FIGS. 14 and 15. As 40 
is well-known to those skilled in the art, a computer 
system having a SCSI interface, such as a UUT probes 
the SCSI bus to determine if SCSI devices are present. 
Each SCSI device identifies itself with an identification 
number. This is known as the arbitration phase. Once 45 
ID's have been sampled by the UUT, selection of a 
device may be accomplished. This is known as the se- 
lection phase. After arbitration and selection, the UUT 
can issue a command (such as a read or a write) and the 
device will respond with data. The preferred embodi- 50 
ment senses the issuance of the arbitration and selection 
signals, and simulates a SCSI device with an ID =6, 
which is the default highest priority SCSI ID number 
besides the UUT in a Macintosh brand computer. Other 
responses to probes by the UUT are now discussed. 55 
These are performed, as is well-known to those skilled 
in the art, by sensing the arbitration, selection, and com- 
mand signals sent by the UUT, and device 100 responds 
in a manner expected from a SCSI device. The signals 
issued to the UUT will now be discussed. 60 

The SCSI Test Manager entry process performed by 
the UUT is.shown as 1300 in FIG. 13 (referred to in step 
1219 of process 120)). Process 1300 is performed by a 
UUT when allowed to continue to perform bootstrap 
initialization and has a SCSI device coupled to one of its 65 
ports through port 660. Process 1300 starts at step 1301 
wherein, at step. 1302, a first available SCSI device on 
the bus is selected that has an ID =6 (this is the highest 
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priority SCSI device in a Macintosh brand computer). 
When the UUT requests an access to the SCSI device 
having ID = 6, diagnostic base unit 190 senses this signal 
and transmits responsive data to the UUT via port pack 
160. The fore, at of data responsive to requests issued by 
the UUT is shown in FIG. 14 and is shown in more 
detail in FIGS. 14 and 15. At step 1303, the UUT will 
attempt to read the first 256 bytes of block 0 of this 
simulated device by issuing read commands through 
port 660 to tool 100. Block 0 1401 is shown with refer- 
ence to FIG. 14 This contains the driver descriptor 
map (DDM) for the simulated SCSI partition. The 
UUT attempts, at step 1304, to look for a driver descrip- 
tor map such as 1401 with a value equaling $4552 (this 
indicates that the SCSI device has been formatted). This 
is indicated as field 1501 in FIG. 15. Upon receiving the 
address for the first 256 bytes of block 0 of the unit with 
ID =6, diagnostic tool 100 transmits DDM 1401 onto 
the SCSI bus. Driver descriptor map 1401 comprises 
two portions, 1401 a and 14016. 1401a contains "real 
data" which resides in non-volatile memory of tool 100 
and is transmitted to the requesting UUT. The remain- 
ing portion 14016 of the data is zero-filled and transmit- 
ted to the UUT through port 660 byte-by-byte from a 
register in tool 100. The remaining blocks shown in 
FIG. 14: 1402*, 1403*, 14046, and 14056 are similarly 
zero-filled and transmitted to the UUT. The remaining 
"real" portions of driver descriptor map 1401a is shown 
in FIG. 15. Driver descriptor map 1401a indicates the 
size in blocks of the device in field 1502 (a one word 
field) and the number of blocks on the device in field 
1503 (a 32-bit longword). Blocks are 512 bytes long, in 
a preferred embodiment. Field 1504 indicates the device 
type (a one for disk drive), 1505 has the device ID type 
(one). Field 1506 also contains a one, in the preferred 
embodiment, a value expected by Macintosh brand 
UUTs. The number of driver descriptors is contained 
in field 1507. In this example, there is only one. The 
driver descriptor starts at field 1508. The first block of 
the driver resides at block four as indicated by field 
1508 (a 32-bit longword), and the driver size is exactly 
one block long as indicated by field 1509. Lastly, the 
driver type is of type 1, which is contained in field 1510, 
in the Macintosh brand family of personal computers. 
After the driver descriptor map is read at step 1304, step 
1305 reads the pseudo device driver of the simulated 
SCSI device at block 4, shown as 1405 in FIG. 14. The 
format of blocks 1402 through 1405 are discussed with 
reference to FIG. 16. 

Partition map entries, such as 1402, 1403, 1404, or 
1405 are one-block entries containing information about 
the SCSI partitions which are being accessed. The 
pseudo device driver of the preferred embodiment re- 
sides in one of these partition map entries, and is shown 
as 1405 in FIG. 14. Each of the partition map entries has 
a specific format, which is well-known to those skilled 
in the art, and is set forth in Inside Macintosh, Volume V 
available from Addison- Wesley at pages V-576 through 
V-582. Because the actual data contained within fields 
in blocks such as 1402 through 1405 is well-known to 
those skilled in the art, a detailed discussion of that will 
not be set forth here. Each of the blocks 1402 through 
1405 contains a first portion such as 1402a through 
1405a, which contains real data in order to conserve 
space in the ROM of the preferred embodiment. The 
remaining portions such as 14026 through 14056 contain 
dummy data which is transferred to the UUT when 
request for the remainder of the block is made by the 
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UUT. In each of the partition map entries 1402 through 
1405, the actual portion read in by the UUT, 1402a 
through 1405a, is 64 bytes in length. The remaining 
portions 14026 through 14056 are padded with zeros. 
The partition map entries are then read by the UUT. At 
step 1306, the partition map 1402 for tile operating sys- 
tem is read. Once this is done, the partition map entry 
for the pseudo partition is read at step 1307. Then, the 
partition map entry 1404 for tile driver is read in at step 

1308. This gives the system the address at which to start 
to execute the driver contained in 1405. Then, at step 

1309, the partition map entry for the operating system 
1402 is read again. At step 1310, the driver residing at 
the location indicated by 1404 is called to install itself 
and the driver causes a jump to the Test Manager to 15 
occur. Once process 1300 is complete, at step 1311, the 
Test Manager is running in the UUT, which can now be 
accessed and communicated with by diagnostic tool 
100. 

In summary, diagnostic tool 100, in one embodiment 
of the invention, simulates a SCSI device with an ID = 6 
for a Macintosh brand personal computer. A series of 
requests is made to tile device to read various informa- 
tion off a simulated SCSI device. Blocks are returned 
from this simulated device as shown in FIG. 14 and 
described with reference to FIG. 13, and tile diagnostic 
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Initialing Command 



UUT 
Response 



device 100 returns blocks which are expected by the 
UUT. Blocks are fed to the UUT in tile following order: 
1401, 1405, 1402, 1403, and 1402. As a last step, the 
device driver residing in block 1405 is called to execute 
itself thus causing a jump to occur to the Test Manager 
which resides in the UUT system ROM. 

Once entry into tile Test Manager of tile UUT has 
been perforated, various tests within the Test Manager 
may be accessed and executed. It can be appreciated by 
one skilled in the art that other architectures possessing 
similar test routines may be accessed in a similar man- 
ner. This will allow entry and testing in an automated 
fashion by diagnostic apparatus 100. The commands set 
forth in Table 4 are provided for execution of the Test 
Manager remotely via a coupling with the UUT to 
serial port 640 on port pack 160. Each command is 
preceded by a "*" which indicates that a command is 
following on serial port 640. When a UUT is activated 
and the Test Manager is entered, in one embodiment, 
the serial port of the UUT defaults to a 9600 baud con- 
figuration and expects "*" commands to be received via 
serial port 640 coupled to the serial port of the UUT. 
Responses to tests requested by diagnostic apparatus 
100 are also provided across the serial port. Specific 
commands are summarized as follows: 

TABLE 4 

Command Name Description 



*L xx xx xx xx 



*B xx xx 



Stop initial input 
message and Start 
UUT ROM " 
Monitor 



Lead address 



♦Dxx 



•C xx xx xx xx 



*G xx xx xx xx 



*Oxx xx xx xx 



•2 IT 



Byte count 



Download data 



Checksum data 



Go . . . (execute) 



O — low or bottom 
RAM test address 



\ = high or top 



Read CPU 
register 



This command is the "handshake" that 
initializes the UUT ROM monitor to accept 
test commands. It also silences the UUT 
(if the UUT sends out a repeating error 
message upon failure or if the ROM 
monitor has been invoked). 
This command is followed by 4 bytes that 
specify the address where the UUT will 
start loading (or downloading) data into 
RAM. Response indicates that the UUT 
received the valid command (handshake). 
Can be used to load tests into the UUT. 
This command is followed by 2 bytes that 
specify the number of bytes to be 
downloaded. (*L must precede this 
command). Response indicates UUT 
received the valid command (handshake). 
This command is followed by xx xx (2 hex) 
bytes as specified by the *B command. 
(*L & *B must precede this command). 
Response indicates UUT received valid 
command (handshake). 
This command requests memory range 
checksum specified by starting location 
and number of bytes (via *L and *B 
respectively). Returns checksum followed 
by 'C. Must be used with «L and *B. 
This command is followed by 4 hex bytes 
that specify the address where the UUT 
will start running a program. (To run a 
downloaded program, *L, *B, and *D must 
precede this command). Response 
indicates UUT received the valid command 
(handshake). 

This command is followed by 4 hex bytes 
that specify the address where the UUT 
will start running a RAM test (A 
pointer). Response indicates UUT 
received the valid command (handshake). 
This command is followed by 4 hex bytes 
that specify the address where the UUT 
will start running a RAM test. (A 
pointer). Response indicates UUT 
received the valid command (handshake). 
Requests CPU register data 
specified by rr. Response returns 
32-bit register information from 
the UUT CPU register, rr. The 
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TABLE 4-continued 



UUT 

Initialing Command Response Command Name Description 



•3 rr xx xx xx xx *3 



•4 



Write CPU 
register 
Registers: 
D0-D7 SP 
A0-A6 SR 

Clear UUT error 
register, (e.g., 
D6.L & D7.W) 

Re-enter ROM 
monitor 



*A ASCII mode 



*H Hex mode 



*R xx xx xx xx xx xx *R Result request 



»M xx. 



*M Memory dump 



Echo 



*1 Initialise 



*T tt tt pp pp oo oo *T ROM-resident 
Test request 



register dump is followed by *2 to 
indicate the end of transmission. 
Writes 32-bit value to register specified 
by rr. 

Example: »3D301F9AB35*3 

•2SP 00OE952*2 

Underlined section returned by Test 
Manager) 

Clears the error storage registers on 
the unit under test. Response indicates 
UUT received the valid command 
(handshake). 

Re-starts ROM monitor entry and re-calls 
generic header (e.g., 
•APPLE*xxxxxxxxxxxx*l*). Response 
indicates UUT received the valid command 
(handshake). 

Sets ASCII character mode. Sends and 
receives ASCII data. Response indicates 
UUT received the valid command 
(handshake). 

Sets hex character mode. Sends and 
receives hex data. Response indicates 
UUt receives the valid command 
(handshake). 

Requests current status or test results. 
Response returns a 12-character result 
code that specifies the current error 
status. 

Requests memory data specified by *L and 
*B (*L and *B must precede this 
command). Response returns memory 
information as specified by the *L and *B 
commands. The memory dump is 
followed by *M to indicate the end of 
transmission. 

Requests the UUT to echo externally 
transmitted characters back to the 
external device. Response indicates UUT 
received the valid command (handshake). 
Requests the UUT to re-initialize itself. 
This terminates serial communications. 
(Re-boot). 

Requests the UUT ROM test to be run. 
This command is followed by 8 hex bytes; 
"u u" is the "pass count" (or number of 
times test is to be run); "oo oo oo 00" is 
the option word. Response indicates UUT 
received the valid command (handshake). 
Examples of ROM Test number (tt tt) 
activities: 

0000 - Size Memory 

0001 - DataBus Test 

0002 - Mod3Test 

0003 - Addrline Test 
00W - ROMTest 

0005 - Rev3ModTest 

0006 - StartUpROMTest 



An additional feature provided by the Test Manager 
is the ability to download specific tests into the Test 
Manager. This is performed using the "*D" command 
and such tests may be executed by typing in the "*G" 55 
command with the address of the test loaded using the 
"*D" command. The last command in any user-speci- 
fied test using "*D" must jump back to the starting 
address of the Test Manager to provide the appropriate 
response to diagnostic tool 100. It can be appreciated by 60 
one skilled in the art that a variety of entries into sys- 
tem-specific test functions such as the ones provided 
above may be performed. 

Tests Requiring the Test Manager 65 

Most of tile tests run ell diagnostic tool 100 require 
the UUT to be in the Test Manager. This requires the 
machine to have'a limited amount of functionality. Most 



of these tests download a piece of code into the UUT to 
run in the native environment. If the user attempts to 
run one of these tests without being in the Test Man- 
ager, he will be given a prompt to enter the Test Man- 
ager by diagnostic tool 100. In order to enter the Test 
Manager automatically, each test requires that the UUT 
be coupled to ports 660 and 610 or 620 using appropri- 
ate cables. Also, tool 100 must be coupled to the UUT 
through port 630 using a serial cable to communicate 
with the Test Manager. 

ROM Checksum (ROMck)— This test checksums all 
of the ROM's in the CPU (if more than one exists). This 
test will not identify individual ROM failures. This test 
fails if the checksum does not match the one stored in 
the ROM, otherwise it passes. 
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RAM Size (RAMsz) — This test determines the size of and written to the chip. This test also measure the sound 

the RAM in the CPU. The test finds the largest SIMM out for volume and frequency. This test gives pass or 

in the bank and uses that to determine the size. For fail only. 

example, if the test finds three 256K SIMM's and one 1 ADB Test (ADB)— This test verifies that the ADB 

Meg SIMM, it will size the machine to 4 Megs. This test 5 (mouse and keyboard) transceivers, the portions of the 

has no pass or fail. It reports the size of memory it finds VIA that control ADB, the ADB line and the ADB 

and indicates if it thinks the memory is misconfigured (a port is functional. This test gives pass or fail only. This 

system where the largest SIMM's are in bank A instead test requires that both ADB cables be connected from 

on bank B) or bad (which may just be mismatched (a the UUT to ports 610 and 620. 

system which has different size SIMM's in the same 10 Video Card Test (Video) — This test determines what 

bank)). video cards are in what slots and builds a menu for the 

Address Test (Addr.) — This test checks the address user. The user can select which card he wants to test, 

lines of the CPU. It determines if the lines are function- The test will then test the RAM on the selected video 

ing properly. This test has pass or fail only. card. This test runs on the Macintosh II, IIx, and Ilex 

Databus Test (Data) — This test checks the data lines 15 brand family of personal computers. This test gives 

of the CPU. It determines if the lines are functioning graphic representation of which SIMM's are bad or fails 

properly. This test graphically shows catastrophic er- the card if the soldered SIMM's are defective, 

rors and missing SIMM's. Floppy Drive Test (Drive) — This test determines 

SIMM's Test (SIMMs) — This test uses the results what floppy drives are in what ports and builds a menu 

from RAM Size to read and write RAM to determine if 20 for the user. The user can select which drive he wants 

it is good. This test graphically shows catastrophic to test. It then tests the ability of the drive to read, write, 

errors, missing SIMM's and individual bad SIMM's. and seek. This test gives pass or fail only. 

VIA Test (VIA)— This test checks the VIA's (Versa- Power Off CPU— This test shuts off power to the 

tile Interface Adaptors or Peripheral Controller Chips) CPU. This test funs on Macintosh II, IIx, and Hex 

for functionality. This test gives pass or fail only. 25 brand family of personal computers. 

Clock Test (Clock) — This test checks the UUT real Thus, an invention for diagnosis for computer sys- 

time clock chip for functionality. This test gives pass or terns has been described. Although the present inven- 

fail only. tion has been described particularly with reference to 

Parameter RAM Test (P/RAM)— This test verifies FIGS. 1 through 15, it will be apparent to one skilled in 

that the PRAM (parameter RAM which controls data, 30 the an, however, that the present invention has utility 

and mouse information) can be read from and written far exceeding that disclosed in the figures. It is contem- 

to. This test gives pass or fail only. NOTE: There are plated that many changes and modifications may be 

two modes of operation for this test One mode saves made, by one of ordinary skill in the art, without depart- 

and restores the contents of PRAM (parameter RAM of ing from the spirit and scope of the present invention as 

the UUT), and the other mode clears out all of PRAM. 35 disclosed above. 

SCC Test (SCC)— This test verifies that the SCC What is claimed is: 
chip functions in all modes and that the serial bus can 1. A device for terminating a bus comprising: 
send and receive data correctly. This test gives pass or a. first means for activating termination of the bus; 
fail only. b. second means coupled to the first means for sup- 
SCSI Test (SCSI) — This test verifies that the SCSI 40 plying power, the second means supplying power 
(small computer system interface) chip functions in all upon activation of the first means; 
modes and that the SCSI bus can send and receive data c. third means coupled to the second means for limit- 
correctly. This test gives pass or fail only. ing voltage received from the second means; and 

SWIM/IWM Test (SWIM) — This test determines if d. fourth means coupled to the third means for limit- 

the CPU has an IWM or a SWIM (floppy disk control- 45 ing transient voltages on the bus. 

ler chips) connected and then tries to initialize the chip. 2. The device of claim 1 wherein the first means com- 

This test gives pass or fail only. This test can only detect prises a flag. 

catastrophic failures in the IWM/SWIM. The floppy 3. The device of claim 1 wherein tile second means 

drive tests provide a more comprehensive test of the comprises a MOS-FET wherein the source of the MOS- 

chip. 50 FET coupled to a power supply, drain is coupled to the 

FPU Test (FPU) — This test verifies that the FPU third means, and tile gate is coupled to the first means, 

chip (floating point math coprocessor) functions. This 4. The device of claim 1 wherein the third means 

test runs on Macintosh II, IIx, Ilex brand family of comprises a low dropout voltage regulator, 

personal computers. This test gives pass or fail only. S. The device of claim 1 wherein the fourth means 

Sound Test (Sound) — This test verifies that the sound 55 comprises at least one diode, 

chip registers function and that data can be read from * * * * * 
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ABSTRACT 



On board diagnostic capability for a SCSI controller is 
provided within an adapter by providing a gate array 
driven by a microprocessor on board the adapter. The 
gate array has data and control inputs driven from the 
microprocessor and data and control outputs which are 
dot OR'ed with corresponding in/out terminals of the 
SCSI controller. A reset signal from a SCSI bus forms 
a further input to the gate array. For testing purposes 
the microprocessor drives the gate array inputs to simu- 
late a fault-free or faulty device. The microprocessor 
detects the response of the SCSI controller to the de- 
vice simulation and thereby can determine the state of 
health of the SCSI controller. 

9 Claims, 3 Drawing Sheets 
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the SCSI devices as a SCSI adapter. Thus the SCSI 
ON BOARD DIAGNOSTIC SUB-SYSTEM FOR SCSI adapter has a port coupled to a first bus which first bus 
INTERFACE is coupled to a port of the computer system. The SCSI 

adapter has a second port which is coupled to the SCSI 
FIELD OF THE INVENTION 5 bus and via that bus to one or more SCSI devices. Typi- 

The invention relates to testing devices complying call y tne SCSI adapter includes a SCSI controller as a 
with the Small Computer System Interface (SCSI) and component. 

more particularly to a system with on board testing and . One problem raised by the SCSI interface is caused 
diagnostic capability for : devices such as a SCSI con- by the inability to assume a particular configuration of 
troller. 10 devices connected on the SCSI bus. Because no config- 

_ . „ „„_ uration can be assumed, it is not possible to select spe- 

BACKGROUND OF THE INVENTION dfic , est procedureSi for execution/based on the config- 

Diagnostic subsystems have, in the past, been applied uration. For example one configuration may require a 
in at least two different applications. In one application, collection of printers, another configuration may in- 
diagnostic systems and sub-systems have been used as a lJ elude a collection of read only CD ROMS, another 
part of the manufacturing process. More particularly, configuration may have a plurality of read/write hard 
after a product is manufactured it is connected to a files, a different configuration may have all of the above 
diagnostic system or sub-system to insure that the manu- and finally a further configuration may include devices 
fact ured device meets manufacturing specifications and _ still being developed. The inability to assume a particu- 
is in condition for sale. In an entirely different applica- 20 jar device configuration, coupled with the limitations a 
tion, diagnostic sub-systems have been included as part particular device may provide in testing many of the 
of computer systems. Typically such an on board diag- modes of operation requires a new and effective test 
nostic sub-system is initiated into operation as part of capability which is effectively independent of the de- 
Power On Reset (PGR) sequence each time the com- - vices co nnecte( i on t h e SCSI bus. 
puter system . is powered up or reset. The diagnostic 25 a second problem is the necessity to isolate defects in 
sub-system performs a routine of tests and either allows the Mvm and receivers in the SCSI adapter or more 
normal pr^mg to be mttiated if the tests are success- particu i arlv> the SCSI controller conta i n ed in the 
fully passed or reports some information about any tests ad often if ^ drjvers and receivefs ^ defecti 

which are not successfully completed _ the defects cannot be isolated between the adapter, the 

One problem faced by the diagnostic sub-system de- 30 v ' 

signer is typified by the expandable nature of the Per- came or tne aevice. 

sonal Computer (PC). More particularly the nature and * th,rd P roblem 15 the tes,ln 8 ?™ronment. The test 
complement of devices included in the computer system sub - s y stem ma > opmte m an environment in which it is 
cannot be predicted. This unpredictability limits the n f the autonomous bus master this is particularly true 
extent and nature of the diagnostics. Prior art I/O de, 3J of ^ SCSI environment. While m the SCSI environ- 
vices, for example hard files, are associated with a de- ment the ada P ter usuall y has the h, « hest P™nty> never- 
vice controller, and the device controller is usually ,heless other dev,ces ma y attain contro1 of the bus Md 
tested with the device connected to the controller. that condition must be respected; furthermore there 
Prior art ST506 and Enhanced Small Device Interface ma y be more ,han a sm 6le adapter on the bus. As a 
(ESDI) devices are examples of this architecture. 40 result the diagnostic sub-system must take into account 
More recently, with the advent of the SCSI standard, tne presence of other devices which may be connected 
logic which is dedicated to operation of devices such as on the bus - If the diagnostic sub-system assumes control 
a hard file has been moved from the controller to the of the SCSI bus > il » conceivable that it can interfere 
hard file assembly itself. This leaves a generic interface * e operation of other bus users to the detriment of 

which actually operates as a low cost network and is 45 the entire system. 

capable of supporting hard files, diskette drives, CD SUMMARY OF THE INVENTION 

ROM drives, printers etc. This new architecture re- 
quires a completely different method of testing the The invention solves the foregoing problems and 
SCSI controller from those used in the ST506 and provides an advance in the art as follows. In one form of 
ESDI arrangements. See in this regard, "Solving the 50 the invention, the SCSI controller, component of the 
Test Problem in SCSI Disk Drives" appearing in Elec- SCSI adapter, is coupled to the SCSI bus and more 
tronics, page 3J at seq., Feb. 17, 1986; Robinson, "SCSI particularly to eight data conductors, a data parity con- 
Interface Demands New Test Methods", Mini-Micro ductor, a C/D (commands/data) conductor, a MSG 
Systems, page 35, April, 1988; Squires, "Outsmarting (message) conductor, a I/O (input/output) conductor, a 
Smart Interfaces to Test Winchester Drives", Electron- 55 SEL (select) conductor, a BSY (busy) conductor, a 
ics Test, February, 1988; "Western Digital Slashes SCSI REQ (request) conductor, an ACK (acknowledge) con- 
Bus Overhead Time" in Electronics, Aug. 20, 1987 and ductor, and a RST (reset) conductor. Dot OR'ed to the 
Aseo, "Disc Interfacing Gets Smart", ESD: The Elec- C/D, I/O, MSG, SEL, BSY, REQ, ACK and parity 
tronics System Design Magazine, page 77, November conductors of the SCSI controller are the outputs of a 
1987. 60 diagnostic gate array. The gate array has eight data 

The SCSI or generic interface raises a number of output conductors which are dot OR'ed with the eight 
testing issues especially with respect to the SCSI inter- data conductors coupled to the SCSI controller data 
face between a system, such as a Personal Computer I/O terminals. The outputs of the gate array are derived 
system, and a plurality of devices coupled to the SCSI from a plurality of registers contained in the diagnostic 
interface through a SCSI bus. Although in prior devices 65 gate array. Inputs to the diagnostic gate array are pro- 
the hardware between a system and a peripherial device vided by a dedicated micro-processor, dedicated to the 
was identified as a controller this application will refer adapter. The micro-processor output which is coupled 
to the hardware interfacing the computer system and to the diagnostic gate array includes eight data bits, 
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write select control signals and a wrap (test) control BRIEF DESCRIPTION OF THE DRAWINGS 
signal. A further input to the diagnostic gate array is a 

signal appearing on the RST conductor of the SCSI The invention will be further described in the follow- 

DUS ihg portions of this specification when taken in conjunc- 

With the capability afTorded by the diagnostic gate 5 tioh with the attached drawings in which: 

array, the SCSI controller can be exercised by diagnos- ? IG r 1 18 a block diagram of a micro computer system 

tic microcode and the outputs of the diagnostic gate '"eluding an adapter 20 its associated interface and a 

array, also driven by the micro-processor can simulate P 1 ^, of d ' v,ce * « ^f led *? ^ m ?? ct > 

the response of an attached device operating either in a 1ft * » a ^ °f pte . r 20; 

r u *~ „ , „ i. j ■ 10 FIG. 3 is a further detail of the adapter 20 showing a 

fault-free or purposefully . sunula ted fault mode, and ^ $CSI controller m md , ^ Q ^ c gate 

generally m both modes. Dwgnostic microcode which £ b ^ whh , he t i* ventio * ^ 

exercises the SCSTcontroller causes the SCSI control- FIG. 4 is a schematic of the diagnostic gate array 220. 
ler to select itself thereby eliminating the possibility of 

corrupting the integrity of devices connected to the , 5 DETAILED DESCRIPTION OF PREFERRED 

SCSI bus. Diagnostic microcode, coupled through the EMBODIMENTS 

diagnostic gate array simulates a SCSI device attached FIG. 1 is a block diagram of a typical microcomputer 

to the SCSI bus to thereby test the arbitration, selection, system 10 showing, in detail, an adapter 20 coupled to 

re-selection and read/write functions of the SCSI con- and controlling a plurality of devices 61-63 through a 

troller. Testing can put the SCSI controller in both an 20 bus .50. The bus 50 is coupled to a port 25 on the 

initiator and target modes using DMA and automatic adapter. In addition, the adapter 20 includes a port 23 

PIO methods where appropriate. The diagnostic micro- through which the adapter is coupled to the bus 30. In 

code can also implement phase and parity testing. a specific embodiment of the invention the adapter 20 

The testing can be implemented with or without the comprises a SCSI adapter e.g., an adapter conforming 

SCSI bus connected to the SCSI connector on the 25 10 the SCSI standard. The adapter 20 has a port 25 

adapter, so long as the connector is properly termi- coupled to a SCSI bus 50 which in turn connects each 

nated. Because the input/output terminals of the SCSI 10 a plurality of devices 61-63. Devices 61-63 can be 

controller are dot OR'ed to outputs of the diagnostic ^ ° f a y ^ of penpheral devwes conforming to the 

„„,„, .__;„ „r . cfer k„. 0 „j/„, ,v. _,„ SCSI standard such as hard files, floppy disc drives, 

gate array, the presence of a SCSI bus and/or the pres- ,„ . __ ■ .,' rr ' , * 

~ „ r a-.a„L, ,„ t t,„ c« CT i.V,„ ; „ ",„„ 30 pnnters, CD ROMS, etc. As will be more completely 

encc of devices connected to the SCSI bus is com- *, ., ' . , .. . . , .■ 

. . . . . , . . . • , .. .. • , desenbed below the SCSI adapter 20 includes a diag- 

pletely immaterial to the diagnostic operation (again ^ subsystem which Mows \ hc adapter 20 to u*t a 

assuming proper termination to prevent signal reflec- scs] ^ntt^r included within the adapter 20. FIG. 2 

to ° nS '" ... , ... is a block diagram of the adapter 20 showing several of 

Accordingly, in one aspect the invention provides 3J the c6mponents therein including a peripheral device 

device adapter capable of controlling a variety of pe- controller 201 which can, for example, be a SCSI con- 

ripheral devices each designed to comply with a Small ^1^. controller 201 is coupled through the port 

Computer System Interface (SCSI) standard, said de- 25 to the SCSI bus 50. The controller also, is coupled 

vice adapter including: oyer a bus 206 to a dedicated micro-processor 202 (such 

a connector for connection to a SCSI bus; 40 as the Intel 80188) and to ROM 203 and RAM 204. The 

a micro-processor and dedicated memory coupled micro-processor 202 is coupled to a Buffer & Data Flow 

thereto; Control element 205 and to a System Interface Control 

a SCSI device controller coupled to and driven by 206. The System Interface Control 206 is coupled via 

said micro-processor, said SCSI device controller in- the port 23 to the bus 30. The adapter 20 also includes 

eluding dedicated input/output terminals for driving +5 an intelligent buffer 207 coupled to the SCSI controller 

selected conductors of said SCSI bus and for respond- 201 through the Buffer & Data Flow Control element 

ing to selected conductors of said SCSI bus, and ? 05 - F1G - 2 does not show the diagnostic sub-system 

a gate array with a set of inputs coupled to said mi- which can be incorporated as is shown in FIG. 3. FIG. 

cro-processor and a set of outputs coupled in common 3 snows * e bus 206 coupling the micro-processor 202 
with said input/output terminals of said SCSI device 50 10 the scsl controller 201 and the relationship of the 

controller micro-processor 202 to the ROM 203 and RAM 204. 

It should be apparent from the foregoing that the FIG. 3 shows u, detail a plurality of input/output termi- 

diagnostic gate array, in combination with other ele- ° f the S ^ I c c ° n,roUer W J^t/bu*iit terminals 

menta of the SCSI adapter, allows diagnostic operations „ m ? Ud . e & ST) > ^ ^tT^ 

either in the manufacturing process o -as part of a POR 55 P u i, ^ /0 >' mes "f' (MSG)> f"^™ (A ™>' 

°* v (SEL), busy (BSY), request (REQ), acknowledge 

SC *J UCn , Ce ', . , , , . (ACK), and parity terminals. Each of these terminals is 
In the form of the mvenhon aheady described the connected vi H a a dedicated co „ductor to a correspond- 
diagnosuc gate array and the SCSI controller may be ■ terminal m tne rt or connector 2S through which 
implemented as separate electronic chips. However in w these termmft ls are connected to the SCSI bus 50. In 
another (or second) form of the invention the diagnostic addition, the SCSI controller 201 includes eight data 
gate array can be integrated with the SCSI controller to input/output terminal each of which is connected to a 
form a single electronic chip. This single electronic different conductor and therethrough to a correspond- 
chip, in accordance with the second form of the inven- j ng terminal in the connector or port 25. 
tion, may include the functions attributed to the SCSI 65 FIG. 3 also shows the diagnostic gate array 220. The 
controller and the functions attributed to the diagnostic diagnostic gate array 220 includes an input from the bus 
gate array in accordance with the description of the first 206, coupling signals generated from the dedicated mi- 
form of the invention. cro-processor 202. The diagnostic gate array includes 
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an output terminal for each of eight data conductors, as array 220, that detection will cause the state of the flip 
well as for each of the following: ACK, REQ, BSY, • - flop FF.to change. The change in state of the flip-flop 
SEL, PARITY, MSG, I>0, and C/D. Conductors from FF will disable each of the gates OA1-OA16. Accord- 
each of these output terminals are connected to the ingly, the gate array 220 will respond to the reset signal 
corresponding conductor coupled between a like input- 5 on the SCSI bus as any other SCSI device is required to 
/output terminal of the SCSI controller 201 and the respond by the standard. 

port or connector 23. The diagnostic gate array 220 also In order to test the SCSI controller 201 the micro- 
includes a further input terminal RST which is con- processor 202 (driven by a micro-code) from either 
netted to the conductor coupling the SCSI controller ROM203 or RAM204, first commands the SCSI con- 
terminal RST to the port or connector 25. 10 trolier 201 to arbitrate for control of the SCSI bus. This 

FIG. 4 is a block diagram of one preferred embodi- ensures that iesting of the SCSI controller 201 will not 
rnent of the diagnostic gate array 220 of FIG. 3. More interfere with any other transactions which may be 
particularly, as shown in FIG. 4 the bus 206 provides 12 simultaneously taking place across the SCSI bus. On 
input signals to the diagnostic gate amy 220: These successfully arbitrating for control of the bus, the SCSI 
signals include eight bits of data D0-D7, two register IS controller 201 then proceeds to select itself, e.g. it iden- 
select signals, CSl and CS2, a Write control signal arid tifies the target device as the device with its own ID. 
a WRAP control signal. The thirteenth input to the The micro-processor 202 then drives the gate array 220 
, diagnostic gate array 220 is provided at the RST termi- with a sequence of signals. Those signals can simulate 
nal which is coupled to the RST terminal at port 25 and . the normal response of any target device to the SCSI 
to the RST terminal of the SCI controller 201. 20 controller 201. The micro-processor 202 then monitors 

The gate array 220 includes two registers, REG1 and the status of the SCSI controller 201 to ensure that the 
REG2. Each of the registers has eight data input termi- SCSI controller 201 properly responds to the simulated 
rials, each coupled to one of the input terminals D0-D7. - response generated by the gate array 220. In addition, or 
Two additional inputs to the gate array. 220 are the in lieu of the foregoing the micro-processor 202 can 
control signals CSl and CS2. The presence of either 25 drive the gate array 220 with a simulation of an error 
CSl or CS2 selects trie associated element either REG 1 condition (PARITY overrun, etc.) and also monitor the 
or REG2 for writing the contents of D0-D7. The infor- response of the SCSI controller 201. In this fashion the 
mation is written in the joint presence of the appropriate SCSI controller may be tested whether or not any de- 
select signal (CSl or CS2) along with the Write signal, vice is connected to the SCSI bus (so long as the bus is 
another input from the bus 206. 30 properly terminated) and if a device is so connected 

Each of the registers, REG1 and REG2, has each of regardless of its identity or characteristics. Further- 
its eight output terminals connected to a different one of more, by controlling the pattern of signals written to the 
a plurality of output gates OA1-OA16. The other input gate array 220 the response of the SCSI controller 201 
terminal to each of me gates OA1-OA16 is provided by to fault-free or faultv devices can be detected by the 
the output of a gate G4 which is one element of a bista- 35 micro-processor 202. 

ble element or flip-flop FF , formed by gates G1-G4. Although not illustrated, in the second form of the 
The two inputs to the flip-flop FF are the RST signal invention, the gates and registers of FIG. 4 are inte- 
and the WRAP signal Assuming that RST is absent (or grated into the structure of the SCSI controller 201. As 
inactive) then assertion of WRAP partially enables each a result the dot OR'ed connections of FIG. 3 are no 
of the gates OAl-OAi6 to repeat, at its output, the 40 longer external to the SCSI controller but rather are, in 
other input provided from the associated terminal of the second form of the invention, internal to the SCSI 
one Of the registers REG1-REG2. Eight of the outputs controller 201. In other respects the two forms of the 
of the gate array 220 are the signals DATA0-DATA7 . invention have similar operational characteristics, 
which, as shown in FIG. 3 are dot OR'ed with the It should be therefore apparent that many other and 
signals provided by the DATA terminals of the SCl 45 further changes can be made within the spirit and scope 
controller 201. The other eight outputs of the gate array of the present invention. The present invention is not to 
220 are the control signals ACK, REQ, BSY, SEL, be limited by the examples described herein but is to be 
PARITY, MSG, I/O and C/D. construed in accordance with the claims attached 

From the foregoing it should be apparent that the hereto, 
micro-processor 202 can, by providing the appropriate 50 We claim: 

signals over the bus 206, drive any of the 16 output 1. A device adapter capable of controlling a variety 
terminals of the gate array 220 in any desired sequence of peripheral devices each designed to comply with a 
or pattern. More particularly, the data stored in any specific standard, said device adapter including: 
stage of either of the registers REG1 or REG2 is con- a connector for connection to a multiconductor bus; 
trolled by transmitting the appropriate bit on that one of 55 a micro-processor and dedicated memory coupled 
the conductors, D0-D7 associated with the selected thereto; 

stage of the register, and asserting either CSl or CS2 a device controller coupled to and driven by said 
depending on which of the registers the stage appears micro-processor, said device controller including 

in, along with the Write signal. Once the registers dedicated input/output terminals for driving se- 

REG1 and REG2 have been loaded with the appropri- 60 lected conductors of said multiconductor bus and 
ate data, assertion of WRAP will produce the cone- for responding to selected conductors of said multi- 

sponding data at the output of the gate array 220. conductor bus, and 

The RST input, since it is connected via the port 23 to a gate array with a set of inputs coupled to said mi- 
the RST conductor on the SCSI bus, will follow the cro-processor and a set of outputs coupled in com- 

state of the RST conductor on the SCSI bus. 65 mon with said input/output terminals of said de- 

Accordingly, even if the gate array 220 is being vice controller, 

driven by the micro-processor 202, the presence of the 2. A device adapter as recited in claim 1 wherein said 
reset signal on the RST bus will be detected by the gate specific standard is a Small Computer System Interface 
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standard and wherein said gate array includes a Reset 
.input coupled to said multiconductor cable. 

3. A device adapter capable of controlling a variety 
of peripheral devices each designed to comply with a 
Small Computer System interface (SCSI) standard, said 
device adapter including: 

a connector for connection to a SCSI bus; 
a micro-processor and dedicated memory coupled 
thereto; 

a SCSI device controller coupled to and driven by 
said micro-processor, said SCSI device controller 
including dedicated input/output terminals for 
driving selected conductors of said SCSI bus and 
for responding to selected conductors of said SCSI 
bus, and 

a gate array with a set of inputs coupled to said mi- 
cro-processor and a set of outputs coupled in com- 
mon with said input/output terminals of said SCSI 
device controller. 

4. A diagnostic subsystem for use with a Small Com- 
puter System Interface (SCSI) adapter where said Small 
Computer System Interface (SCSI) adapter includes a 
micro-processor., and dedicated memory coupled 
thereto, and a SCSI controller coupled to said micro- 
processor and to a SCSI bus, said diagnostic subsystem 
including: 

a gate array coupled, to said micro-processor and to 
said SCSI controller and, also coupled to said SCSI 
bus, 

said subsystem further including: 

means responsive to a diagnostic command received 
at said SCSI controller for selecting said SCSI 
controller and for generating and coupling, 
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through said gate array, signals simulating a re- 
sponse of an attached device. 
5. A diagnostic subsystem as recited in claim 4 
wherein said means responsive to a diagnostic com- 
5 mand for generating signals simulating an attached de- 
vice includes means for simulating a fault free attached 
device. 

.6. A diagnostic subsystem as recited in claim 4 
wherein said means responsive to a diagnostic com- 
10 mand for generating signals simulating an attached de- 
vice includes means for simulating a faulty attached 
device. 

.7. A diagnostic subsystem as recited in claim 4 
wherein said gate array includes a plurality of register 
IS stages, each coupled to an input terminal of said gate 
array, first logic means responsive to command signals 
for enabling at least one of said register stages to store 
information representative of a signal appearing at said 
input terminal, and second logic means for coupling 
20 information stored in said at least one register stage to 
an output terminal. 

.8. A diagnostic subsystem as recited in claim 7 
wherein said second logic means includes: 
a reset input terminal coupled to a reset signal carry- 
25 ing conductor included in said SCSI bus, and 
means responsive to an active reset signal for dis- 
abling said second logic means from coupling in- 
formation to said output terminal. 
9. A diagnostic subsystem as recited in claim 8 
30 wherein said second logic means includes a wrap test 
input terminal, and means responsive to a transition of 
said wrap test signal for enabling said second logic 
means. 

« * • « ♦ 
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A computer system comprises a CPU, a main memory, 
and plurality of I/O Processors (IOPs), coupled to each 
other by a system I/O bus. The IOPs perform slave 
processing functions relating to I/O devices. A simula- 
tion protocol is defined for the IOPs, whereby the host 
CPU can command an IOP to execute a simulation 
script. The simulation script defines one or more I/O 
devices to be simulated, and specifies a simulated work- 
load associated with the devices. The IOP executes the 
simulation script by sending simulated input streams to 
the host and receiving output destined for the simulated 
I/O devices from the host on the system I/O bus. An 
IOP may simulate multiple I/O devices, and may simu- 
late I/O devices concurrently with servicing real I/O 
devices. In typical use,, one or more applications pro- 
grams will execute on the CPU concurrently with the 
execution of one or more simulation scripts in the IOPs 
attacked to the system I/O bus. The behavior of the 
system under such conditions can be used for capacity 
planning forecasts, for developing and debugging the 
application software, for reproducing and diagnosing 
intermittent error conditions, or for performing other 
tasks in which it is necessary to determine the character- 
istics of the system under hypothetical conditions. 

22 Claims, 8 Drawing Sheets 
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METHOD AND APPARATUS FOR SIMULATING 
I/O DEVICES 

This application is a continuation of U.S. patent appli- 5 
cation Ser. No. 07/781,460 filed Oct. 23, 1991, now 
abandoned. 

FIELD OF THE INVENTION 

The present invention relates to data processing sys- 10 
tern design, and in particular to a design for supporting 
the simulation of physical devices attached to a com- 
puter system and workloads imposed on the system. 

BACKGROUND OF THE INVENTION 15 

Modern computer systems are increasingly being 
used to perform a large variety of difficult data gather- 
ing and analysis tasks. With the growing prevalence and 
complexity of computers, it is frequently desirable to 
obtain information and answer questions about the com- 20 
puter system itself. Due to the complexity of the ma- 
chine, it is difficult to obtain useful information purely 
by manual methods. Since the computer has been used 
to solve such a large variety of problems, it is only 
natural that the computer be used for introspective tasks 25 
as well. For example, computer systems have been de- 
signed with capabilities to diagnose hardware failures, 
provide performance and usage information, assist de- 
bugging of programs, etc. 

■ When solving introspective problems, a computer is 30 
often required to answer hypothetical questions. It may 
need to know how it would respond to a given external 
workload, how long it would take to run a particular 
program, what would be the effect of temporary loss of 
a hardware component, etc. One type of application in 35 
which such questions must be answered is the capacity 
planning application. Capacity planning involves fore- 
casting future workload to be imposed on a computer 
system, predicting how the system will respond to such 
workload, and determining how such response may be 40 
improved (as by attaching additional hardware to the 
system). Another such application is hardware and soft- 
ware development, in which it is desirable to know how 
a system will respond to a hardware or software compo- 
nent under development in a variety of prospective 45 
environments. Still another possible application is in 
defect diagnosis, particularly defect diagnosis of an 
intermittent error condition, in which re-creation of the 
intermittent error condition requires that a particular 
environment be assumed. Another possible application 50 
is performance analysis and diagnosis, in which it is 
necessary to determine how the system behaves under 
given conditions and how system behavior can be al- 
tered. 

In theory, it is possible to duplicate the hypothetical 55 
conditions with actual hardware running appropriate 
software on behalf of real users. In reality, such a solu- 
tion is seldom practicable. For example, a commercial 
enterprise planning for future expansion may wish to 
know how its system would respond to increased work- 60 
load from a larger number of attached terminals and 
interactive users. In theory it could buy the required 
equipment, hire the terminal operators, create addi- 
tional workload for input to the system, and observe the 
results. In reality, such an approach is prohibitively 65 
expensive. In another example, a software development 
house may wish to know how its software will behave 
on a particular family of computer systems, under a 
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variety of system configurations and workloads. It 
could buy all the hardware required to duplicate the 
various configurations, hire the required number of 
interactive users, and observe the results; again, this 
approach would be prohibitively expensive and time 
consuming. In addition to being prohibitively expensive 
and time consuming, the duplication of real conditions 
as described above is frequently undesirable because it is 
impossible to obtain repeatable results. When real users 
enter data at a keyboard, there will naturally be some 
variation in the actual timing of input streams, causing 
observed results to vary. In some applications, such 
variation is a serious drawback. For example, a devel- 
oper who is attempting to diagnose an intermittent error 
condition will want to establish a repeatable sequence of 
events by which the error condition can be induced. 

Another approach to providing data for hypothetical 
problems is the use of special purpose hardware simula- 
tors, which take the place of attached devices with real 
users. Such hardware simulators obviate the need for 
live interactive users, and can be made to generate simu- 
lated workload in a repeatable manner. However, hard- 
ware simulators are still a very expensive method of 
providing this information. Typically hardware simula- 
tors are more expensive than the devices they replace. 
As a result, the use of hardware simulators is generally 
confined to system development laboratories. 

It is possible to create simulation software. This soft- 
ware attempts to duplicate the hypothetical conditions 
by issuing instructions from the central processing unit 
(CPU), causing simulated workload to be processed by 
the system. Such software is adequate for some tasks, 
but often lacks the ability to simulate many conditions 
on the system. The computer system typically com- 
prises a single CPU, which is coupled to various mem- 
ory devices and slave processors via one or more com- 
munications buses. The slave processors are in turn 
coupled to I/O devices such as disk drives, interactive 
workstations, printers, etc., or may be coupled to other 
slave processors. System behavior will depend not only 
on the number and type of such devices, but the connec- 
tion topology as well. Simulation software running in 
the CPU will not always accurately represent the state 
of other parts of the system, in particular the slave pro- 
cessors and I/O devices. 

When a computer performs introspective tasks, it 
may obtain some information from the operator, but 
generally the source of its information is the computer 
itself. As with any task performed on a computer, the 
quality of the output information can be no better than 
the quality of the input. Unfortunately, the computer 
systems of the prior art lack the ability to obtain accu- 
rate information for answering many hypothetical ques- 
tions at reasonable cost. 

SUMMARY OF THE INVENTION 

It is therefore an- object of the present invention to 
provide an enhanced method and apparatus for per- 
forming introspective tasks on a computer system. 

Another object of this invention is to provide an 
enhanced method and apparatus for simulating devices 
attached to a computer system. 

Another object of this invention is to provide an 
enhanced method and apparatus for simulating a work- 
load input to a computer system. 

Another object of this invention is to increase the 
accuracy of information in a computer system concern- 
ing hypothetical devices and workloads. 
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Another object of this invention is to reduce the cost BRIEF DESCRIPTION OF THE DRAWINGS 
of providing accurate information concerning hypo- 
thetical devices and workloads in a computer system. FIG. 1 shows the major hardware components of a 

Another object of this invention is to provide an computer system having means for simulating I/O de- 
enhanced method an apparatus for performing capacity 5 yi ces according to the preferred embodiment of this 
planning tasks on a computer system. invention; 

Another object of this invention is to increase the „ FIG - 2 shows ™) or components of a typical I/O 

accuracy of capacity planning forecasts for a computer P/ocessor assembly of a computer system accordmg to 

svstem r the preferred embodiment; 

. !, , . . , iL . . - , . , 10 FIG. 3A shows the high-level format of a typical 

Another object of this invention to provide an en- . ^ . . ,. °^ . f , v ,. 

. \ _ . . . . . simulation scnpt accordmg to the preferred embodi- 

hanced method and apparatus for developing software mem v 

for a computer system. FIG. 3B shows the format of a typical simulator 

Another object of this invention to provide an en- octroi Wock within the simulation script according to 

hanced method and apparatus for diagnosing problems 15 the p re f er red embodiment; 

in a computer system. FIG. 3C shows the format of a typical data stream 

Another object of this invention is to perform com- control block within the simulator control block ac- 

puter system device and workload simulations with cording to the preferred embodiment; 

increased accuracy and repeatability. FIG. 3D shows the high-level format of a typical data 

A computer system comprises a CPU, a main mem- 20 stream script according to the preferred embodiment; 

ory, and a (IOPs), coupled to each other by one or more FIG. 3E shows the format of a data stream command 

system I/O busses. The IOPs perform slave processing contained in the data stream script according to the 

functions relating to the I/O devices. Each IOP con- preferred embodiment; 

tains a programmable processor. Each I/O device at- FIG. 4 is a high-level flowchart of the steps involved 

taches to the system via an IOP, and all communications 25 in simulating I/O devices according to the preferred 

between it and other elements of the system must pass embodiment; 

through the IOP FIG. 5 is a flowchart of the steps performed by the 

A simulation protocol is defined for the IOPs, IOP c ° ntro1 P u ro S" m when simulating an I/O device 

whereby the CPU executing instructions resident in m ^Jl 1 * 11 *} 0 d ^Tl top * , 

' j , nTi . . . 30 FIG. 6 shows the steps performed by the IOP control 

main memory can command an IOP to execute a simu- when ^ ^ stream accordi t0 

latum script. The simulation scnpt defines one or more & e i referred embodiment. 
I/O devices to be simulated, and specifies a simulated 

workload associated with the devices. The IOP exe- DETAILED DESCRIPTION OF THE 
cutes the simulation script by interacting with the sys- 35 PREFERRED EMBODIMENT 
tem I/O bus as if real I/O devices attached to the IOP A diagram of the major hardware components of a 
were performing the work indicated in the script. For computer system with the capability to simulate I/O 
example, if an interactive workstation is being simu- devices according to the preferred embodiment of the 
lated, the IOP may send simulated input data strings to present invention is shown in FIG. 1. Computer system 
the CPU at intervals, and receive output from the CPU 40 100 comprises a central processing unit (CPU) 101 cou- 
intended for interactive display on the simulated work- pled to a system random access memory 102. System 
station. memory 102 is in the address space of CPU 101. Al- 
It is not necessary that any of the simulated I/O de- though it is shown as a single unit, it should be under- 
vices actually exist on the system. A single IOP may stood that it may in fact comprise a hierarchy of mem- 
simulate more than one I/O device, and more than one 45 ory devices, such as a small, relatively fast cache mem- 
type of I/O device, and multiple IOPs may simulate ory and a slower but larger main memory, as is known 
multiple I/O devices simultaneously. Real I/O devices « the art. CPU 101 and memory 102 are coupled to bus 
may operate concurrently with the simulation, form the interface unit 103, which arbitrates control of system 
same IOP and from different IOPs. Thus, virtually any I/° bus 105 Md handles communications between bus 
hypothetical configuration of I/O devices to the system 50 105 ™ d cpu ™ or memory 102. System 100 may 
may be simulated comprise more than one system I/O bus. It is shown in 

¥ »_:„i „„ ' „ „, ,„ „i:„„,;„„„ FIG. 1 with a second bus interface unit 104 connected 

In typical use, one or more applications programs ^ , ,„, _ , ... ... ^ ^ . - 

... ,r . .1 , , • •» »i to unit 103. The second unit 104 arbitrates control of a 

will execute on the central processing unit concurrently . „ T //->u a „ ...-.i, 

... . ^. „ r r . ^ ■ ^ • second system I/O bus 106, and communicates with the 

with Ae execution of one or more simula^n scnptsm * ^ CRJ and m 

the IOPs attached to the system I/O bus. The IOPs will y fa bus ^ m Buses 105 106 ^ a 

simulate, through execution of the simulation scripts, communications path t0 a plurality of I/O processors 

input to the applications programs that would be ex- ln _ u8 . I/D processors handle communications with 

pected from real I/O devices during normal use. The j/q devices, and may control some of the function of 

IOPs will also receive and acknowledge output pro- w suc h devices. Various different types of I/O processors 

duced by the application programs, destined for the exist on S y Stem 100. Each storage I/O processor 

simulated I/O devices. The behavior of the system 111-113 controls a high-speed I/O channel for servic- 

under such conditions can be used for capacity planning jng storage devices such as magnetic disk drive direct 

forecasts, for developing and debugging the application access storage devices (DASD), magnetic tape drive, 

software, for reproducing and diagnosing intermittent 65 and diskette drive. Workstation I/O processors 114-116 

error conditions, or for performing other tasks in which service local interactive workstations and printer 

it is necessary to determine the characteristics of the through a plurality of direct local connections. Commu- 

system under hypothetical conditions. nications I/O processors 117-118 service remote com- 
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munications lines and token ring local area network, gle electronic circuit card on which are mounted a 

which may attach to additional I/O devices or other plurality of electronic components, said components 

computer systems (which will appear to system 100 as being electrically connected with each other via various 

I/O devices). It should be understood that the number, circuits contained in one or more planes of printed cir- 

type and configuration of I/O devices, I/O processors 5 cuitry on the circuit card. However, the I/O Processor 

and other components may vary. A computer system assembly could be contained in multiple circuit cards, 

according to this invention may contain a single system or on a part of a single circuit card, or on a single chip. 

I/O bus or may contain multiple buses. Different types From the perspective of that part of the system on the 

of I/O processors may be present in the system, includ- host side of the IOP (Le., the CPU, system memory, 
ing multi-function I/O processors which perform the 10 . system I/O bus, other IOPs, etc.), the IOP is the I/O 

function of more than one type of I/O processor. Dif- device or devices which are attached to it. The CPU 

ferent types of I/O devices may be present, such as and/or main memory receive input data streams from 

optical storage devices, optical character readers, voice the IOP over the system I/O bus, and send output data 

I/O devices, etc. In addition, system 100 may be a multi- streams to the IOP over the system I/O bus. The es- 

processor system, comprising a plurality of central pro- 15 sence of the invention disclosed herein is that the IOP, 

cessing units. In the preferred embodiment, system 100 by generating and accepting data streams that would 

is an IBM Application System/400 system. normally be received from and sent to an I/O device, 

The major components of a typical I/O Processor can effectively simulate the I/O device to the host part 

assembly (IOP) 201 of the preferred embodiment are of the system. 

shown in FIG. 2. The I/O Processor assembly com- 20 According to the preferred embodiment a simulation 
prises a programmable processor 202, a locally address- protocol is defined for the IOPs. This protocol defines a 
able memory 203, system I/O bus interface circuitry procedure whereby the CPU, executing instructions 
206, and device interface circuitry 207, which are cou- resident in main memory, can issue a command to an 
pled to each other via various communications paths as IOP to execute a simulation script. The simulation 
shown. Locally addressable memory 203 comprises 25 script, whose format is defined by the protocol, is trans- 
non-volatile portion 205 for storing instructions and ferred from the main memory to the IOP for execution, 
vital data required for start-up of the IOP, and dynamic The script is a shorthand description of actions to be 
portion 204. The purpose of the IOP is to relieve the taken by the IOP to simulate one or more I/O devices. 
CPU of the burden of performing all I/O support by The script may be viewed as a series of commands 
itself. The IOP supports I/O devices by driving high- 30 which the IOP executes, but each "command" may call 
speed I/O channels, workstation lines, or other commu- for a complex series of actions by the IOP rather than a 
nication lines. The IOP may also handle direct memory single instruction executed by the IOP's programmable 
accesses between the system memory and an I/O de- processor. A portion of the IOP's control program 
vice. In the case of workstations, the IOP may also resident in IOP local memory 203 decodes each block 
perform various tasks relating to updating the display, 35 of the script and may expand it into the series of actions 
such as processing of data keystrokes, cursor move- required of the IOP to simulate the I/O devices). The 
ment, scrolling, etc. Thus, the CPU is shielded from the IOP then executes the actions called for by the ex- 
details of such I/O support, and will only hear from an panded script Execution involves interacting with the 
I/O device when the device has some input ready for system I/O bus as if real I/O devices attached to the 
the system. 40 IOP were performing the work meant to be simulated 
In operation, the IOP's programmable processor 202 by the script Data streams typical of what the I/O 
executes instructions contained in a control program device would generate are generated by the'IOP instead 
210 stored in locally addressable memory 203. Memory and placed on the system I/O bus, bound for the CPU, 
203 may also serve as a cache for temporary storage of main memory, or other system component. Outbound 
data being transferred between the system I/O bus and 45 data streams from the host, destined for the I/O device, 
an I/O device. Processor 202 is capable of moving data are received and acknowledged by the IOP and prc- 
or issuing commands, status information, etc. to either cessed by it as if a real I/O device were attached, but no 
system I/O bus interface circuitry 206 or device inter- data is in fact transmitted by the IOP to an I/O device, 
face circuitry 207. Data may also be moved through FIG. 3A shows the high-level format of a typical 
memory 203, by-passing processor 202. 50 simulation script 301 according to the preferred em- 
In the preferred embodiment, IOP 201 is a worksta- bodiment. In this embodiment, the IOP is a workstation 
tion controller to which a plurality of interactive work- controller to which a plurality of interactive worksta- 
stations may be attached. The IOP maintains a screen tions may be attached, it being understood that this 
buffer and field format table for each workstation it invention could be practiced with other types of IOPs, 
serves in dynamic memory 204. The screen buffer stores 55 including multi-function IOPs. The simulation script 
the contents of the current display screen at the work- comprises a one-byte control block count field 302, one 
station; the field format table identifies the location of or more simulator control blocks 303-305, and one or 
entry fields. The buffer and field format table enable the more data stream scripts 310-319. Block count 302 
workstation controller IOP to process certain key- indicates the number of simulator control blocks 
strokes received from the workstation without inter- 60 303-305 in script 301. In the example of FIG. 3, three 
vention from the host For example, cursor movement simulator control blocks 303-305 are contained in the 
keystrokes can be processed by updating the screen script, and block count 302 is accordingly set to "3". 
buffer. Each simulator control block defines a single I/O de- 
It should be understood that, as used herein, an I/O vice to be simulated. Each data stream script defines a 
Processor refers to an entity performing slave process- 65 simulated input data stream (in this case, simulated key- 
ing functions relating to I/O. Many different IOP de- strokes) that the IOP will process as if received from the 
signs exists in computer systems. In the preferred em- keyboard of an interactive workstation to generate an 
bodiment, the I/O Processor assembly comprises a sin- inbound data stream. The inbound data stream is then 
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transmitted on a system I/O bus as if it originated from marily the data stream portion 3S3 between the com- 
the interactive workstation. Multiple data stream scripts mands consists of individual bytes representing key- 
may be associated with each simulated I/O device. In strokes from the simulated workstation. In the preferred 
the example of FIG. 3, four data stream scripts are embodiment, a think time command is defined for the 
associated with the first simulated I/O device, and three 5 data stream portion, which causes the IOP to insert a 
data stream scripts are associated with each of the other specified time delay in the data stream. The time delay 
simulated I/O devices. In addition, control blocks asso- specified in the command is multiplied by the think time 
ciated with different simulated I/O devices may share multiplier specified in field 344 of the data stream con- 
one or more data stream scripts. trol block. 

FIG. 3B shows the format of a typical simulator 10 FIG. 3E shows the format of a data stream command 
control block 303, which is part of simulation script 301. 351 contained in the data stream. The command com- 
Simulator control block 303 comprises the fields de- prises a 1-byte escape code to signal the start of the 
scribed below. Block length field 321 (at byte locations command 361, a length field 362 indicating the length 
0-1) is a two-byte field containing the total length (in (in bytes) of the command, a command code 363 identi- 
bytes) of the simulator control block. Device Id field 15 fying the command, a second length field 366 and 1- 
322 and model ID field 323 identify the type and model byte escape field 367. Fields 366 and 367 make the com- 
of the I/O device (in this case, a workstation) being mand a symmetric series of bytes, enabling it to be read 
simulated. Keyboard ID field 324 and extended key- either forward or backward. Command 351 optionally 
board ID field 325 identify the type of keyboard at- contains additional command parameters 364. Where 
tached to the simulated workstation. Device address 20 additional parameters 364 are present, a second corn- 
field 326 identifies the logical address within the IOP of mand code field 365 is necessary to maintain symmetry, 
the simulated workstation. The system-wide address of In the example of FIG. 3E, the command is a start 
a workstation is a combination of the address of the IOP command, having 10 bytes of additional parameters 
and the address within the IOP of the workstation. specifying the data stream script length and identifier. 
Delay time field 327 contains the delay time (in seconds) 25 The operation of the present invention according to 
from the start of a simulation until the IOP is to begin the preferred embodiment will now be described. FIG. 
executing the data stream scripts called out by the simu- 4 is a high-level flowchart of the steps involved. A 
lation control block. Stream count field 328 identifies simulation is initiated from the host side of the system, 
the number of data stream control blocks contained in Simulation may be initiated either by a call from an 
simulator control block 303. A variable number of data 30 application program running on the host CPU or by a 
stream control blocks 329-332 (not fewer than three) command entered from an interactive terminal (step 
follow stream count field 328. The data stream control 401). The simulation script 301 may be imbedded in the 
blocks occupy byte locations 10 through (9+ll*N), application program or may be a separate file. The 
where N is the number of such control blocks, as application program or user who initiated a simulation 
shown. Each data stream control block 329-332 identi- 35 may initiate simulations in multiple IOPs simulta- 
fies a data stream script to be executed by the IOP. End neously, which may use the same or different simulation 
byte 333 signals the end of simulator control block 303. scripts. FIG. 4 shows the simulation steps only for a 

FIG. 3C shows the format of a typical data stream single IOP, it being understood that multiple IOPs 

control block 330, which is part of simulator control could be performing the steps shown in FIG. 4 simulta- 

block 303. The data stream control block is used to 40 neously. 

identify the data stream script and control its execution. For example, a capacity planning application pro- 
While each data stream control block is associated with gram may test a hypothetical configuration and work- 
a data stream script, it is possible for one data stream load by calling one or more simulation scripts, execut- 
script to be shared by multiple control blocks, enabling ing the scripts and measuring the system response. In 
multiple simulated I/O devices to use the same data 45 another example, a software developer developing a 
stream script. In the example of FIG. 3C, data stream software module may command the IOPs to execute 
control block 330 is associated with data stream script one or more simulation scripts while the software mod- 
311. Data stream control block 330 comprises the fields ule is executing; the simulation scripts could merely 
described below. Script length field 341 identifies the provide typical background work for the system or may 
length (in bytes) of the corresponding data stream 50 invoke the software module under test directly. In a 
script. Offset field 342 identifies the starting location of further example, a system developer might use the sys- 
the data stream script in the simulation script record as tem console to invoke simulations for debugging inter- 
an offset (in bytes) from the beginning of the record. mittent error conditions; once a simulation script can be 
Keying rate field 343 identifies the rate (in characters constructed to induce the intermittent error, it can re- 
per second) at which keystrokes are to be simulated. 55 peatably be induced any number of times, and the be- 
Think time multiplier field 344 contains a multiplier havior of the system observed. 

used to calculate response times from the workstation Upon initiation of the simulation, the host sends a 

(simulating thinking by the interactive user). Loop command to the IOP to begin simulation, along with 

count field 345 indicates the number of times that the the simulation script (step 402). The script is stored 

data stream script should be executed before continuing 60 somewhere on the host side of the system, which could 

to the next script. End byte 346 signals the end of the be in main memory, disk storage or elsewhere, and is 

data stream control block. downloaded to the IOP via the system I/O bus. The 

FIG. 3D shows the high-level format of a typical data IOP stores the script in its local memory 203 for the 

stream script 311. The data stream script is a variable duration of the simulation. In the preferred embodi- 

length stream of commands and individual bytes repre- 65 ment, the simulation script is not kept in the IOP local 

senting keystrokes. It is delimited by start command 351 memory 203 during normal operation, although that 

and end command 353. Between the start command and portion of the IOP's control program responsible for 

end command may exist additional commands, but pri- decoding the script and executing it is. The download- 
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ing of simulation scripts from the host permits greater specified length of time m the middle of the data stream, 

flexibility in the content of the simulations, since it is The data stream script is repeated the number of times 

possible for the host to store a variety of simulation specified in loop count field 345 of data stream control 

scripts. However, in an alternative embodiment it block 330. When the IOP finishes executing a data 

would be possible to store a standard simulation script 5 stream script, it proceeds to the next script. When all 

permanently in the IOP as part of its control program. middle data stream scripts have been executed, the IOP 

Upon receipt of simulation script 301, the IOP stores loops back to the first middle script (the second data 

the script in local memory 203 and parses the various stream script) and repeats the sequence. The middle 

control blocks of the script (step 403). Script 301 will data stream scripts are repeated indefinitely until a stop 

contain one or more simulator control blocks 303-305, 10 command is received from the host 
each block corresponding to one I/O device to be simu- As in the case of the log-on script, the host responds 

lated. The IOP will send a power-up message to the as necessary to the various input streams received as a 

host for each simulated workstation. The power-up result of the middle data stream scripts (step 410). For 

message informs the host that the interactive worksta- example, a middle data stream script may produce in- 

tion has just been powered-up, and is awaiting instruc- IS bound data streams to first call an editor program to edit 

tions from the host. At the same time, the IOP allocates a document, then make random character insertions and 

a screen buffer and field format table for each simulated deletions in the document, and finally save the edited 

workstation in its local memory. The host will normally document. To each of these data streams, the host 

respond by sending a log-on screen to the workstation, would respond, for example, by displaying the docu- 

just as it would if a real workstation had powered-up 20 ment initially, updating the document on the worksta- 

(step 404). tion display as alterations are made, and transmitting 

The following described steps are executed sepa- appropriate save messages to the workstation display, 

rately for each simulated workstation. The IOP control Note also that the data streams may cause various parts 

program in effect has separate workstation sessions of the host to respond, as for example reading from and 

operating in parallel, just as it would for multiple real 25 writing to disk storage as the document is initially called 

interactive workstations. up and later saved. 

Upon receipt of each log-on screen, the IOP starts a When the IOP receives a command to stop simulation 

timer for the simulated workstation to wait an initial from the host (step 411), it completes processing of the 

delay time before executing a simulated log-on by an current data stream script, then executes the final data 

interactive user (step 406). The delay time is the time 30 stream script, which is a log-off script (step 412). After 

specified in delay time field 327 of simulator control the host responds by acknowledging the log-off and 

block 303. Since a separate simulator control block 303 returning the display to an idle state (step 413), the IOP 

exists for each simulated device, it is possible to have sends a power-down message to the host indicating that 

different delay times, enabling staggered log-on of the the simulated workstation has been powered down, 

simulated users. 35 This completes the simulation. 

After waiting the delay period, the control program FIG. 5 shows in greater detail the steps performed by 

in the IOP executes the first data stream script, which the IOP control program to simulate each workstation, 

by convention is the log-on script (step 407). The log-on which are represented in the high-level diagram of FIG. 

script is executed only once. The IOP executes the data 4 as steps 405,406,407, 409,412. When the IOP receives 

stream script by decoding any imbedded commands in 40 acknowledgment of power-on from the host and the 

the script and taking appropriate action, by processing log-on display, it sets a timer to the delay value specified 

the stream of data bytes contained in the script as if the in field 327 (step 501). It then waits idle until the timer 

same were received from a real workstation to generate expires (step 502). Upon expiration of the timer, a 

inbound data, and transmitting on the system I/O bus pointer to the current data stream script is initialized to 

the inbound data streams thus generated from the script. 45 the first script and a loop counter is initialized to 1 (503). 

For example, in the case of the log-on data stream The IOP then processes the current data stream script 

script, the script would typically contain a start com- by parsing the script, building inbound data streams to 

mand 351, followed by a string of characters corre- the host, transmitting the streams, and receiving the 

sponding to the user's identifier, password, optional host's response (step 504). The details of processing a 

log-on parameters, and appropriate delimiters such as 50 data stream script are shown in FIG. 6. When the data 

tab keys or enter keys (together constituting part 352), stream script has been fully processed, the IOP checks 

followed by an end command 353. Start and end com- for the presence of a stop command from the host (step 

mands 351, 353 are to be distinguished from commands 505). If no stop command has been received, it then 

received from the host; commands 351, 353 are used increments the loop count variable L (step 506) and 

only as delimiters of the data stream script, not to com- 55 checks whether L exceeds the loop count specified in 

mand the IOP to take some particular action. The host field 345 (step 507); if not flow proceeds to step 504, 

responds to the log-on script in the normal manner (step where the data stream script is repeated. If the loop 

408) , as if a real user were logging on to the system. count has been reached, the current data stream pointer 
After executing the first (log-on) data stream script, is incremented to the next data stream script and the 

the IOP executes the "middle" scripts in sequence (step 60 loop count is reset to 1 (step 508). If the pointer now 

409) . The middle scripts comprise all data stream scripts points to the last data stream script (step 509), the 
other than the first and last. As in the case of the log-on pointer is reset back to the second script (step 510). 
script, each middle script is executed by processing a Flow then proceeds to step 504. If at step 505, it was 
stream of data bytes contained in the script, taking ap- determined that a stop command has been received, the 
propriate action for any imbedded commands, and 65 current data stream script pointer is set to the last script 
transmitting to the host on the system I/O bus the out- (step 511), which is the log-off script, and the script is 
bound data streams generated as a result. For example, processed in the same manner as die previous scripts 
an imbedded command may require the IOP to pause a (step 512). The IOP then transmits a device power- 
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down message and frees that part of dynamic RAM 
allocated to the screen buffer and field format table for 
the simulated device (step 513). When all simulating 
devices have powered-down, that part of dynamic 
RAM allocated to storage of the simulation script is S 
freed. 

FIG. 6 shows the steps performed by the IOP control 
program when parsing a data stream script. The pro- 
gram determines the location of the data stream script in 
local memory from the location of the simulation script 10 
record 301 and offset field 342 of the data stream con- 
trol block (step 601). It then parses the first 16 charac- 
ters, which should be a start command (step 602); if the 
first 16 characters are not a start command, an error 
condition is signalled (step 630). A byte pointer for 15 
identifying bytes within the data stream script is set to 
the starting location of the data stream script plus the 
length of the start command (step 603); this is the loca- 
tion immediately after the start command. The inbound 
data stream destined for the system I/O bus is initialized 20 
to blank (step 604). 

The program then parses the data stream script one 
byte at a time. If the byte being parsed is not '00'X (step 
605), it is processed in the same manner as . a keystroke 
received from the workstation as if the workstation 25 
really existed (step 606). The IOP of the preferred em- 
bodiment maintains state information concerning the 
workstation display in its screen buffer and field format 
table. Certain keystrokes, such as cursor movement or 
tab keys, cause the IOP to update this state information 30 
without sending anything to the host. Other keystrokes, 
such as alphanumeric characters, are typically added to 
an inbound data stream to be sent to the host. However, 
the data stream is not sent immediately to host, but is 
sent following an Attention Identifier (AID) key, such 35 
as the "Enter" key or a function key. Still other key- 
strokes may cause the IOP to edit the inbound data 
stream, as in the case of a backspace or cursor move- 
ment followed by typing over a previously entered 
input field. 40 

When the keystroke has been processed, the byte 
pointer is incremented (step 607), and the IOP verifies 
that the byte pointer does not exceed the bounds of the 
data stream script record (step 608). If the length has 
been exceeded, an error, is indicated (step 630). If not, 45 
and the key just processed was not an AID key (step 
609), the simulation program waits a period of time 
equal to 1 /(keying rate specified in field 343) at step 610. 
This delay simulates a typical delay between keystrokes 
from an interactive user. It then goes to step 605 to 50 
parse the next byte of the data stream script. 

If an AID key is processed (step 609), the inbound 
data stream is transmitted to the host on the system I/O 
bus (step 611). The IOP then waits for the host's re- 
sponse (step 612), which is typically the next display 55 
screen. When a response is received, flow reverts to 
step 604. Typically, a data stream script for a worksta- 
tion will include a think time command immediately 
after an AID key. 

If the byte being parsed at step 605 is '00'X, a com- 60 
mand is indicated. In this case, the command code byte 
(field 363) is examined. If the command is a think time 
command (step 620), the simulation program waits the 
specified think time period multiplied by the time multi- 
plier specified in field 344 (step 621), increments the 65 
byte pointer by the length of the command (step 622), 
and flow goes back to step 605. If the command is any 
other command except an "End" command (step 623), 



the command is executed (step 624) and flow reverts to 
step 605. Although only the start, end and think time 
command are defined in the embodiment described 
herein, numerous other commands are possible and may 
be defined as part of the simulation protocol. For exam- 
ple, a "percent jump" command could be defined, in 
which a branch to another location in the data stream 
script is taken a specified percentage of the times that 
the command is executed, the decision whether to take 
the jump in any particular case being made by generat- 
ing a random number as is known in the art. Such a 
command has the advantage of introducing random 
effects into the simulation, which may be desirable in 
certain circumstances. As another example, a "call" 
command could be defined, in which another data 
stream script is called and executed, control returning 
to the original data stream script when an "end" com- 
mand is encountered in the called data stream script. 

If an "end" command was indicated at step 623, the 
program verifies proper location of the end command, 
which should be at starting location plus offset (field 
342) plus length of data stream script (field 341) minus 5 
(the length of an end command), at step 625. If an error 
in end command location was indicated at step 611, the 
program branches to handle the error (step 630). If the 
end command is in the proper location, the data stream 
script has been successfully processed, and the program 
returns to executed the next step shown in FIG. 5. 

In the preferred embodiment described herein, the 
data contained in the data stream script represents data 
received by the IOP from the workstation. This data is 
processed by the IOP just as it would process data from 
a real workstation. Portions of the IOP behave exactly 
as they would for a real workstation. Screen buffers and 
field format tables are maintained, and the control pro- 
gram processes keystrokes that look like real data, thus 
achieving a truer simulation. However, in an alternative 
embodiment, the data stream script could represent 
inbound data to the host, in which case little or no 
processing of the data would be required by the IOP. In 
the case of certain types of workstations and IOPs, 
there is little difference between the data the IOP re- 
ceives from the workstation and the data it transmits to 
the host For example, ASCII workstations would typi- 
cally require very little processing of the data from the 
data stream script in the IOP. It will be recognized by 
those skilled in the art that the present invention could 
easily be adapted to IOPs servicing ASCII workstations 
(in either block mode or raw mode). 

Because the IOP processor and memory function for 
the most part in their normal manner when processing 
simulated data, it is possible for an IOP to service one or 
more real interactive workstations concurrently with 
simulation of one or more workstations. The IOP will 
maintain a separate screen buffer and field format table 
in local dynamic memory 204 for each workstation, real 
or simulated. The control program will process data 
from each workstation, real or simulated, in the same 
manner. The only difference will be that data from a 
real workstation will appear on I/O device interface 
207, while simulated data will be injected into the pro- 
cessor by that part of the control program executing the 
simulation script. 

In the preferred embodiment described herein, the 
simulation script is separated from the IOP control 
program which executes it The IOP control program is 
generic, capable of executing many different simulation 
scripts. Since the control program does not contain the 



08/15/2003, EAST Version: 1.04.0000 



5,440,697 

13 14 

actual text of simulated data streams that will be sent to (a) means for receiving a simulation script from 

the host, it can be relatively compact as appropriate for said system I/O bus, and 

storage in the limited space typically available in IOP (b) means for executing said simulation script to 

local memory. Preferably, simulation scripts are stored simulate an I/O device. 

on mass data storage, such as magnetic disk drives, until 5 2. The computer system of claim 1, wherein said I/O 
the simulation scripts are actually needed to run a simu- processor assembly has means for simulating a plurality 
lation. When needed, a selected script will then be of I/O devices simultaneously, said means for simulat- 
loaded into IOP local memory and executed as de- ing a plurality of I/O devices simultaneously compris- 
scribed herein. In an alternative embodiment, the text to ing said programmable processor and said local mem- 
be sent by the IOP to the host during simulation could 10 ory. 

be stored in the IOP local memory at all times, or could 3. The computer system of claim 1, further compris- 

be stored in other storage devices available to the IOP. ing: 

This text could be imbedded in a simulation control a real I/O device coupled to said I/O processor as- 

program or part of one or more separate simulation sembly via a communications path independent of 

records. 15 said system I/O bus; 

In an additional alternative embodiment, it would not wherein said means for simulating an I/O device 
be necessary to maintain the control program portion comprises means for simulating an I/O device con- 
responsible for executing simulation scripts in the IOP currently with servicing said real I/O device, 
local memory during normal operation. In this embodi- 4. The computer system of claim 1, wherein said 
ment, whenever a simulation is desired, a special Simula- 20 simulation script comprises a plurality of data bytes 
tion program could be loaded into local memory of the representing simulated input data and a plurality of 
IOP, which may or may not contain the imbedded text imbedded commands. 

of the data streams to be sent to the host to achieve 5. The computer system of claim 1, wherein said 

simulation of I/O devices. This alternative would have means for executing said simulation script comprises a 

the advantage of reducing the size of IOP local memory 25 control program having a plurality of instructions 

required to the extent of that part of the control pro- stored in said local memory and which execute on said 

gram required for simulation execution, but would re- programmable processor. 

quire additional complexity in the host operating system 6. A method for performing introspective tasks on a 

to support loading the different versions of IOP code, computer system, having a central processing unit, a 

keeping track of which version is operating, etc. 30 system I/O bus, and an I/O processor assembly coupled 

The simulation script 301 is a record which may be to said system I/O bus, said I/O processor assembly for 

created and transferred as any record in a computer communicating with one or more I/O devices attached 

system. It would, for example, be possible to create a to said I/O processor assembly via a communications 

simulation script with a general purpose file editor, path independent of said system I/O bus, said method 

although for large scripts this could prove somewhat 35 comprising the steps of: 

tedious. In the alternative, a special purpose editor receiving a command being transmitted on said sys- 
could be created which would provide interactive sup- tem I/O bus to simulate an I/O device, said com- 
port for generating and editing the simulation script; mand being received by said I/O processor assem- 
e.g. default values for many of the simulation script bly; 

fields could be provided automatically, field locations 40 generating a plurality of simulated data streams, said 

and lengths could be verified, etc., as is known in the simulated data streams simulating data from said 

art. As a further alternative, an application program I/O device, said generating step being performed 

could be created which would capture activity of a real by said I/O processor assembly without assistance 

I/O device during a sample interval and convert it to a from a real I/O device; and 

simulation script. 45 transmitting said simulated data streams on said sys- 

Although a specific embodiment of the invention has tem I/O bus, said transmitting step being per- 

been disclosed along with certain alternatives, it will be formed by said I/O processor assembly, 

recognized by those skilled in the art that additional 7. The method for performing introspective tasks on 

variations in form and detail may be made within the a computer system of claim 6, further comprising the 

scope of the following claims. 50 step of: 

What is claimed is: receiving output destined for said I/O device being 

1. A computer system comprising: simulated from said system I/O bus, said output 

a central processing unit; being received by said I/O processor assembly, 

a system I/O bus coupled to said central processing 8. The method for performing introspective tasks on 

unit; and 55 a computer system of claim 6, wherein: 

an I/O processor assembly coupled to said system said command received by said I/O processor assem- 

I/O bus for communicating with one or more I/O bly commands said I/O processor assembly to sim- 

devices attached to said I/O processor assembly ulate a plurality of I/O devices simultaneously; and 

via a communications path independent of said said generating and transmitting steps generate and 

system I/O bus, said I/O processor assembly com- 60 transmit a plurality of simulated data streams, 

prising a programmable processor for controlling wherein said simulated data streams simulate data 

the operation of said I/O processor assembly and a from said plurality of I/O devices simultaneously, 

local memory for storing instructions which exe- 9. The method for performing introspective tasks on 

cute on said programmable processor; a computer system of claim 6, further comprising the 

wherein said I/O processor assembly has means for 65 step of: 

simulating an I/O device to said system I/O bus, servicing, with said I/O processor assembly, a real 

said means comprising said programmable proces- I/O device coupled to said I/O processor assem- 

sor and said local memory, and further comprising: bly, wherein said servicing step is performed con- 
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currently with said steps of generating and trans- 
mitting said simulated data streams. 

10. A method for simulating real-time performance of 
a hypothetical computer system having a first number 
of I/O devices with a real computer system having a 5 
second number of I/O devices attached to one or more 
I/O processor assemblies, wherein said first number is 
greater than said second number, comprising the steps 
of: 

defining, with said real computer system, a plurality jq 
of I/O devices to be simulated by said real com- 
puter system; 

issuing a command in said real computer system, said 
command directed to an I/O processor assembly of 
said real computer system, to simulate said I/O ]3 
devices to be simulated; 

simulating, with said I/O processor assembly, real- 
time behavior of said I/O devices to said real com- 
puter system, 

wherein said steps of defining a plurality of devices, 
issuing a command and simulating real-time behav- 
ior are performed as part of a capacity planning 
task executed by said real computer system, in 
which information concerning operational charac- 
teristics of said hypothetical system is used to per- 
form said capacity planning task. 25 

11. The method of claim 10, wherein said step of 
issuing a command comprises sending a simulation 
script to said I/O processor assembly, and said simulat- 
ing step comprises executing said simulation script with 
said I/O processor assembly. 30 

12. The method of claim 11, wherein said simulation 
script comprises a plurality of data bytes representing 
simulated input data and a plurality of imbedded com- 
mands. 

13. A method for simulating real-time performance of 35 
a hypothetical computer system having a first number 
of I/O devices with a real computer system having a 
second number of I/O devices attached to one or more 
I/O processor assemblies, wherein said first number is 
greater than said second number, comprising the steps 40 
of: 

defining, with said real computer system, a plurality 
of I/O devices to be simulated by said real com- 
puter system; 

issuing a command in said real computer system, said 45 
command directed to an I/O processor assembly of 
said real computer system, to simulate said I/O 
devices to be simulated; 

simulating, with said I/O processor assembly, real- 
time behavior of said I/O devices to said real com- 
puter system, 

wherein said steps of defining a plurality of I/O de- 
vices, issuing a command, and simulating real-time 
behavior are performed as part of a software devel- 
opment task executed by said real computer system 
to develop a software module, in which informa- 55 
tion concerning operational characteristics of said 
hypothetical system executing said software mod- 
ule is used to perform said software development 
task. 

14. The method of claim 13, wherein said step of 60 
issuing a command comprises sending a simulation 
script to said I/O processor assembly, and said simulat- 
ing step comprises executing said simulation script with 
said I/O processor assembly. 

15. An I/O processor assembly for coupling to a 65 
system I/O bus of a computer system, and for communi- 
cating with one or more I/O devices attached to said 
I/O processor assembly via a communications path 



independent of said system I/O bus, said I/O processor 
assembly comprising: 
a system I/O bus interface; 

a programmable processor coupled to said system 
I/O bus interface for controlling operation of said 
I/O processor assembly; 

a local memory for storing instructions which exe- 
cute on said programmable processor, coupled to 
said programmable processor; 

means for receiving a command being transmitted on 
said system I/O bus via said system I/O bus inter- 
face to simulate an I/O device attached to said I/O 
processor, said means for receiving a command 
including means for receiving a simulation script 
being transmitted on said system I/O bus; and 

means, responsive to said means for receiving a com- 
mand, for simulating said I/O device to said system 
I/O bus, said means for simulating said I/O device 
to said system I/O bus including means for execut- 
ing said simulation script with said programmable 
processor. 

16. The I/O processor assembly of claim 15, wherein 
said I/O processor assembly has means for simulating a 
plurality of I/O devices simultaneously, said means for 
simulating a plurality of I/O devices simultaneously 
including said programmable processor. 

17. The I/O processor assembly of claim 15, wherein 
said means for simulating an I/O device comprises 
means for simulating an I/O device concurrendy with 
servicing a real I/O device attached to said I/O proces- 
sor assembly. 

18. The I/O processor assembly of claim 15, wherein 
said simulation script comprises a plurality of data bytes 
representing simulated input data and a plurality of 
imbedded commands. 

19. The I/O processor assembly of claim 15, wherein 
said means for executing said simulation script com- 
prises a control program having a plurality of instruc- 
tions stored in said local memory which execute on said 
programmable processor. 

20. A computer system, said computer system having 
a first number of I/O devices attached to one or more 
I/O processor assemblies, said computer system com- 
prising: 

means for defining a hypothetical computer system 
having a second number of I/O devices, said sec- 
ond number being greater than said first number, 
wherein at least one of said second number of I/O 
devices is a device to be simulated in real-time by 
said computer system; 

means for commanding an I/O processor assembly of 
said system to simulate said I/O device to be simu- 
lated; 

means in said I/O processor assembly, responsive to 
said means for commanding an I/O processor as- 
sembly of said system to simulate said I/O device 
to be simulated, for simulating the real-time behav- 
ior of said simulated I/O device to said computer 
system, thereby simulating the real-time behavior 
of said hypothetical computer system. 

21. The computer system of claim 20, wherein said 
means for commanding an I/O processor assembly to 
simulate an I/O device comprises means for transmit- 
ting a simulation script to said I/O processor assembly, 
and said means for simulating the real-time behavior of 
said simulated I/O device comprises means for execut- 
ing said simulation script. 

22. The computer system of claim 21, wherein said 
simulation script comprises a plurality of data bytes 
representing simulated input data and a plurality of 
imbedded commands. 
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[57] ABSTRACT 

A diagnostic apparatus for testing devices such as com- 
puter systems, and computer system components such 
as disk drives or printers. The device comprises a main 
unit tKe main unit having a central processing unit for 
executing instructions, issuing commands, and receiving ' 
data from a first device/ The apparatus also has a first 
peripheral unit coupled to the main unit, the first pe- 
ripheral unit having ports for interfacing with the first 
device, the first peripheral unit being interchangeable 
with a second peripheral unit for interfacing with a 
second device. The apparatus also comprises a first 
non-volatile memory unit coupled to the main unit, the 
first non-volatile memory unit comprising a first set of 
tests for the first device, the first non-volatile memory 
unit being interchangeable with a second non-volatile 
memory unit comprising a second set of tests for a sec- 
ond device. These interchangeable parts are provided 
so that the user may test various types of hardware. The 
apparatus further comprises software means for provid- 
ing termination on a bus and methods for simulating 
devices on a bus for remote entry into diagnostic pro- . 
grams. . • ' 

3 Claims, 17 Drawing Sheets 




08/15/2003, EAST Version: 1.04.0000 



U.S. Patent Oct. is, 1994 sheet 1 of 17 5,357,519 




08/15/2003, EAST Version: 1.04.0000 



U.S. Patent 



Oct 18, 1994 



Sheet 2 of 17 



5,357,519 




08/15/2003, EAST Version: 1.04.0000 



U.S. Patent Oct is, 1994 



Sheet 3 of 17 5,357,519 




08/15/2003, EAST version: 1.04.0000 



U.S. Patent Oct. is, 1994 sheet 4 of 17 5,357,519 




650 660 



08/15/2003, EAST Version: 1.04.0000 



U.S. Patent Oct. is, 1994 sheet 5 of 17 5,357,519 




685 684 683 682 681 680 679 678 677 676 675 674 

Figure 6a 



08/15/2003, EAST Version: 1.04.0000 




08/15/2003, EAST Version: 1.04.0000 



U.S. Patent Oct is, 1994 sheet 7 of 17 5,357,519 




08/15/2003, EAST Version: 1.04.0000 



U.S. Patent 



Oct. 18, 1994 



Sheet 8 of 17 



5,357,519 




Figure 9 - Diagnostic Tool Base Unit 
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Figure 10 - Peripheral Port Pack 
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Figure 12c 
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have a variety of interfaces and ports. Each port or 

DIAGNOSTIC SYSTEM interface requires a different connector and/or different 

circuitry to test these ports or interfaces/ For instance, > 

BACKGROUND OF THE INVENTION in addition to generic serial and parallel ports such as / 

1. Field of the Invention 5 RS-232 standard ports or SCSI ports, some computer , 
The present invention relates to the field of diagnostic systems may have manufacturer-specific ports such as 

methods and apparatuses for computer systems. More the Apple Desktop Bus (ADB) brand interface manu- 

specifically, this invention relates to a device and factored by Apple Computer.'Inc. The wide variety of 

method for diagnosing a faulty computer system with- ports, interfaces and other coupling means for various 

out disassembling the system. 10 systems makes it difficult to diagnose the many types of 

2. Description of Related Art computer systems in the marketplace. Because the pa- 
The diagnosis of faulty computer systems, at times, rameters of each interface and/or port must be known 

can be a difficult process. For systems which are incapa- to the individual diagnosing the computer system, it is 
ble of powering up and performing a system bootstrap difficult for one person to diagnose a variety of ma- 
initialization process, determining which components 15 chines. In addition, it is helpful if various types of con- 
are faulty requires substantial time and effort using a nectors are available for coupling to the various systems 
variety of methods. One method of diagnosing a faulty for diagnosis. In summary, no single device possesses 
computer system is to remove components in the com- the necessary characteristics to diagnose various types 
puter system one by one and replace them with compo- 0 f computer systems at all levels of operation, 
nents which are known to work. Such a "trial and er- 20 

ror" approach not only requires an on-hand inventory SUMMARY AND OBJECTS OF THE 

of components which are functional, but also requires INVENTION 

that the computer system be disassembled. This type of cohe object of the present invention is to provide a 

diagnosis requires substantial effort to disassemble and device which can diagnose a computer system incapa- / 

reassemble the system and does not necessarily identify 25 We oif petf orming a syslem ^ et u or boo^^ 

the underlying detect which caused the failure. tialization process. ' 

Yet another method fordiagnosing ; a faulty computer AnoOwr object of the present invention is to provide 

s^tem'is-^ appara-/ a device whkh rfonns nonmtrusive diagnostics of a 

tuses to individual 'components. This process requires comnuter svstem. 

some disassembly of the computer system^to attach' 30 P , , . . , . . 

j. _ 4- v . .v - j i * t-* ' Another object of the present invention is to provide 

diagnostic probes to the individual components. De- . . r . „ 

pending on the location of individual components, this a deV1C f wmch * ^Pf e of diagnosing various types of 

process may take a lot of time to disassemble the faulty computer systems including system-specific connectors 

device. This also requires specialized tools to test indi- *^_i! 1 .rri~;~;._ 

vidual components 35 /Another object of the present invention is to provide , 

For a system which is able to power up and execute a "W^. apparatus which facilitates diagnostics of/ 
a system bootstrap initialization but does not function / a computer system with a minimal level of system- 

properly, diagnosis may be performed using a software specific knowledge by a user. 

utility. Some types of utility programs may diagnose I" 1 "** ^ other objects of the present invention are 
certain faulty components, but if the faulty components 40 provided for by a diagnostic apparatus for testing de- 
arc required to operate the utility, the diagnosis of the ^ces such as computer systems, and computer system 
system will be impossible. Even though the disassembly peripheral devices such as disk drives or printers. The 
of the computer system may not be required to run such apparatus comprises a main unit, the main unit having a y 
a diagnostic program, this program may be limited by /central processing unit for executing instructions, issu- 
the inability to test certain hardware components. 45 m 8 commands, and receiving data from a first device 
Some computer systems perform a software diagnos- 'being tested. In a preferred embodiment, the apparatus 
tic self-test upon a system bootstrap initialization pro- comprises a display and keyboard for communicating 
cess. This type of routine tests various components in with a user of the apparatus. The apparatus also has a 
the system prior to operation to ensure that the system /first peripheral unit coupled to the main unit, the first 
is operating properly. One such diagnostic routine is»50 peripheral unit having ports for interfacing with thV 
known as the "Test Manager" program which forms/ ^ mt device, the first peripheral unit beihg'infef change- 
part "of "the bootstrap initialratioif procedure of the' ^-able'with a second peripheral unit for interfacing with a' 
Macintosh® brand ~ecinip^'''&^laia&'1^om''^p\e second device. The first peripheral unit may, for exam- 
Computer, Inc. of Cupertino, Calif. (Macintosh ® is a pie, be used for testing one computer system such as a 
trademark of Apple Computer, Inc.). This initialization 55 personal computer, and the second peripheral unit may , 
process includes, among other things, initialis ing versa-:' be used for testing a second personal computer, disk 
tile interface adaptor "(VIA) circuits, serial cpmmunica- drive, or printer. The apparatus also comprises a first , 
don controller (SCQ circuits, floppy cfrsk drive inte- non-volatile memory unit coupled to the main unit, the 
grated circuit controllers, small computer system inter- first non-volatile memory unit comprising a first set of 
face controller (SCSI) circuits, and sound device or- 60 tests for the first device. The first non-volatile memory 
cults coupled to the system. These routines, which are unit is interchangeable with a second non- volatile mem- 
embedded in read-only memory (ROM)contained ory unit comprising a second set of tests for a second 
within the system, require that the system be capable of device. These units are provided so that the user may 
activating system power and initializing. If the system test various types of hardware. 

cannot be ini tial iz ed , then certain types of tests may not 65 These and other objects of the present invention are 

be able to be performed. provided for by a device for terminating a, bus. In a 

Another drawback of prior approaches to diagnosing preferred embodiment, the termination on a bus, for 

computer systems is that different computer systems example a small computer system interface (SCSI) may/ 
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be desired. The device comprises a first means for acti- operation of computer systems, however, it may be used 
vating termination of the bus which, in a preferred for testing individual components of computer systems 
embodiment, is a flag in a register. When set, the flag such as hard disk drives, printers, monitors, or other 
switches on SCSI termination, and when- not set (e.g., / peripherals. Diagnostic device 100 comprises several 
cleared) there is no termination. The device farther 5 portions which are shown in their assembled and oper- 
comprises a second means coupled to the first means for/ ating configuration in FIG. 1. Diagnostic device 100 
supplying power, the second means being activated 7 comprises a display 110 for presenting information to 
upon activation of the first means. In a preferred em- the user of the device. Display 110 is one of the many 
bodiment, the second means is a p-channel MOS-FET. liquid crystal displays (LCD's) which are commercially 
The device also has a third means coupled to the second 10 available and well-known to those skilled in the art. 
means for limiting voltage received from the second Diagnostic device 100 further comprises a keypad 120 
means which is a low dropout voltage regulator. Lastly, for indicating command selections and other informa- 
the device has a fourth means coupled to the third tion to device 100. Further device 100 comprises a low- 
means for limiting transient voltages on the bus, which power light emitting diode (LED) 130 indicating when 
prevents the bus from appearing as if any device is IS battery power in the unit is becoming depleted. In order 
coupled to the bus. to provide the utmost flexibility, device 100 comprises 

These and other objects of the present invention are . modules 140, 150, and 160 which are all removable from 
'provided for by a means for remotely entering a'diag-^ device 100 and interchangeable with other modules. 140 
nostic program in a computer system. This method ; and 150 are removable "ROM packs" which provide 
comprises simulating a first device coupled to the com-' 20 different tests and different operating modes for the 
puter system and simulating a driver for the first device / various computer systems or computer peripherals 
coupled to- the computer system. The computer system (hereinafter units under test or UUTs) which may be 
is caused to load the driver and then to call the driver to tested by device 100. 160 is also a removable module 
execute itself in the computer system. The driver con- and is known as a "port pack." Port pack 160 provides 
tains a jump instruction to the diagnostic program caus- 25 computer system ports for the various types of ports 
ing the diagnostic program to then execute. which may be present on a system being tested. ROM 

packs 140 and 150 and port pack 160 will be discussed in 
more detail below. 



BRIEF DESCRIPTION OF DRAWINGS 



The present invention is illustrated by way of exam- r FIG. 4 shows one side 400 of device 100. Side 400 of 

pie and not limitation in the figures of the accompany- 30 device 100 comprises a power switch 410 which is a 

ing in which like references indicate like elements and in single pole, single throw (SPST) rocker switch which is 

which: , used Jo activate power to device 100. Further, device j 

FIGS. 1 through 7 show the external physical config- 100 comprises an adaptor plug 420 which is a miniature 

uration of the diagnostic apparatus. dual conductor plug used for supplying S volt power to' 

FIG. 8 shows a removable port pack and removable 35 unit 100 via an integrated power supply adaptor cable. 
ROM packs in a disassembled configuration used in the Diagnostic device 100 may also be powered by an inter- 
diagnostic device of the preferred embodiment. nal battery when not coupled to a power supply via 

FIG. 9 is a block diagram of the base unit of the plug 420. In addition, as shown on side 400 of FIG. 4, 

diagnostic device. device 100 comprises a female serial port 430 which is 

FIG. 10 is a block diagram of the port pack of the 40 used for coupling device 100 to a modem (modulator/- 

diagnostic device. demodulator) for communication over telephone lines. 

FIG. 11 is a schematic of the software controllable This provides the capability for device 100 to communi- 

SCSI termination apparatus used by the diagnostic de- cate with other devices 100 or UUTs which can be 

vice. remotely tested. Connector 430 is a mini 8-pin serial 

FIGS, \2a-d is a flowchart showing various ways to 45 port connector which conforms to EIA standard RS- 

enter test routines used in the diagnostic device of the 232 signal conventions. The signals and pins on connec- 

preferred embodiment tor 430 are described in more detail in Guide to the 

FIGS. 13 through 15 show the SCSI device emula- Macintosh Family Hardware, Second Edition by Apple 
tion used by the preferred embodiment to enter the Test Computer, Inc. available from Addison- Wesley Pub- 
Manager brand diagnostic program. 50 lishing Company, Inc. (copyright 1990)(heremafter 
TlFTATT FT") DFSfT? TPTTON "Hardware Guide") at pages 357-374. Various ports 
i A1L.Z.U utat-.Kii' 1 and detailed connections to port 430 will be discussed in 

A device and method for diagnosis of computer sys- more detail below, 
terns is described. In the following description, for the 

purposes of explanation, numerous specific details are 55 Removable ROM Packs 

set forth such as circuitry, signal names, signal lines, and For the greatest flexibility in testing various types of 

part numbers are set forth in order to provide a thor- computer systems and other devices with diagnostic 

ough understanding of the invention. It will be obvious, tool 100, ROM packs 140 and 150 and port pack 160 are 

however, to one skilled in the art that the invention may provided which are all removable from main unit 190 of 

be practiced without these specific details. In other 60 device 100 as shown in FIG. 8. These packs may be 

instances, well-known circuits, structures, and tech- replaced with other packs which have different ports 

niques have not been shown in detail in order to not and/or different of tests. As is shown in FIG. 8, port 

unnecessarily obscure the present invention. pack 160 may be coupled to main unit 190 via connector 

Physical Configuration of the Diagnostic Tool * ^S^^^^S^SS^i 
FIG. 1 shows the external physical configuration of detailed description of the signals and the lines on con- 
the preferred embodiment of the present invention. nector 810 will be discussed below 810 provides an 
Diagnostic device 100 is generally used for testing the interface with main unit 190 of device 100 so that com- 
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munication with various peripheral ports on pack 160 
may be accomplished. Port pack 160 may be coupled to 
main unit 190 by affixing 160 to 190 in the direction 
shown as 840 on FIG. 8. This mates connector 810 with 
a corresponding female connector on main unit 190 (not 5 
shown). In addition, 100 comprises removable ROM 
packs 140 and 150 which comprise non-volatile test 
routines and other device or system-specific diagnostic 
programs. As is shown in FIG. 8, each module such as 
ISO comprises a connector such as 820 which is mated 10 
to the main unit 190 to provide access to the test rou- 
tines embedded in the non-volatile memory of each 
ROM pack 140 or 150. Each ROM pack such as 140 and 
150 may be coupled to main unit 190 via a 40-pin Fujitsu 
FCN215QO40-G/O male connector which mates with a 15 
corresponding female connector on main unit 190 (not 
shown). A ROM pack such as 140 may be inserted into 
main unit 190 in a direction shown by arrow 850 in FIG. 
8 to provide communication between main unit 190 and 
ROM packs 140 and 150. 20 

Removable Port Pack 

A more detailed view of the rear 600 of port pack 160 
is shown in FIG. 6. 600 of 160 shows various ports 
contained in one port pack 160 which is designed for 25 
testing various models of the Macintosh brand com- 
puter system family manufactured by Apple Computer, 
Inc. of Cupertino, Calif. Port pack 160 is used for test- 
ing the models Macintosh SE, SE/30, and the Macin- 
tosh II brand family of computers including the IIx. 30 
Ilex, among others. It can be appreciated by one skilled 
in the art, however, that a port pack other than 160 may 
be plugged into base unit 190 of diagnostic device 100 in 
order to provide a different set of ports. In the preferred 
embodiment, port pack 160 has six ports. Base unit 190 35 
may accommodate any number of ports depending on 
the configuration of the port pack. It will be appreciated 
by one skilled in the art, that any number of ports may 
be present on a peripheral port pack in various embodi- 
ments of the present invention. A detailed description of 40 
the ports available on port pack 160 of device 100 
shown in FIG. 6 will now be discussed. 

As is shown in FIG. 6, side 600 of port pack 160 
comprises several ports which interface with Macintosh 
brand computer systems. Port pack 160 comprises two * 5 
Apple Desktop Bus (ADB) brand connectors 610 and 
620, two miniature 8-pin EIA RS-424 standard serial 
connectors 630 and 640, a two-conductor miniature 
audio connector 650 for coupling to audio ports, and a 
25-pin female DB25 SCSI connector 650 for coupling to 50 
devices such as SCSI disk drives and disk drive ports on 
computer systems. ADB ports 610 and 620 are used for 
coupling with ADB brand ports on Macintosh com- 
puter systems for communicating various information 
to and from the computer via devices such as key- 
boards, trackballs, or mice. The pin assignments for 611 
through 614 are shown in FIG. 6 and the corresponding 
signals are described with reference to Table 1 below. 

TABLE 1 M 

Signal Attignmrrttt for ADB Connector 610 

Pia 

Number Sign] Name Signal Description 

611 ADB Kdirecticcal data bus used for input 

and output. It is in open -collector $5 
signal pulled up to +5 V 
through a 470 O resistor on an Apple 
Macintosh brand computer's main 
logic board. 



519 

6 

TABLE 1-continued 



Signal Assignments for ADB Connector 610 



Pin 






Number 


Signal Name 


Signal Description 


612 


POWER.ON 


On the Macintosh II family, a key on 






the keyboard momentarily grounds this 






pin to pin 614 to switch on the 






power supply. On other Apple 






Macintosh brand computers this pin is 






not connected. 


613 


+ 5 V 


+5 volts. 


614 


GND 


Ground. 



A more detailed discussion of the ADB signals and 
devices used in the preferred embodiment is discussed 
in Hardware Guide at pages 287-326. A more detailed 
discussion of signals issued by device 100 for perform- 
ing diagnostics of a computer system is discussed below. 
The pin assignments for connector 620 are the same as 
those used on connector 610. 610 are 620 are indicated 
by their corresponding labels 619 and 629 shown in 
FIG. 6, the ADB icons. Further, each of the connectors 
has a key 615 associated with it such as shown with 
reference to 610, to prevent improper insertion of cables 
into connectors 610 or 620. 

Port pack 160 further comprises two serial ports 630 
and 640. Serial ports 630 and 640 are used for coupling 
to a printer port or a modem port on a system as indi- 
cated by the appropriate labels 639 or 649. As discussed 
above, each of the serial ports in the preferred embodi- 
ment and on port pack 160 conform to the EIA RS-422 
standard signal conventions which are described in 
more detail in Hardware Guide at pages 357-374. The 
pin assignments for serial port 640 is described with 
reference to Table 2 below. The signal assignments for 
the pins on 630 are the same. 

TABLE 2 



Signal Assignments for Mini 8-pin Serial Port Connector 640 



Pin 


Signal 




Number 


Name 


Signal Description 


641 


HSKo 


Handshake output Driven inverted. 
Voh = 3.6 V; Vol = -3.6 V; Rl = 45011 


642 


HSKi 


Handshake input or external clock. Received 
uninverted. 

Vih = 0.2 V; Vil = -0.2 V; Ri = 12Kfl 


643 


TxD- 


Transmit data (inverted). Driven inverted or 
tristated depending on the operation mode. 
Voh = 3.6 V; Vol 3.6 V; Rl = 450Q 


644 


GND 


Signal ground. Connected to logic and chassis 
ground. 


645 


RxD— 


Receive data (inverted). 

Vih = 0.2 V; Vil = -0.2 V; Ri = 12K11 


646 


TxD-r 


Transmit data Driven uninverted or tristated 

depending on the operation mode. 

Voh = 3.6 V; Vol = -3.6 V; Rl = 45011 


647 


OPi 


General-purpose input 

Vih = 0.2 V; VD = -0.2 V; Ri = 12KB 


648 


RxD+ 


Receive data. Received uninverted. 

Vih = 0.2 V; Vu = -02 V; Ri = 12Kn 



The two remaining ports on port pack 160 of the 
preferred embodiment are shown as 650 and 660 in FIG. 
6. 650 is a standard 2-conductor female monaural audio 
miniature jack used for diagnosing the sound capabili- 
ties of the device being tested. This is indicated by the 
sound label icon 659 above the sound jack. The process- 
ing of the signals received from sound jack 650 is dis- 
cussed below. 

Lastly, 160 comprises SCSI connector 660 which is a 
standard 25-pin female DB25 SCSI connector which is 
discussed in more detail in Hardware Guide at pages 
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375-396. SCSI connector 660 is labelled by icon 669 as 
shown in FIG. 6. The circuitry coupled in main unit 190 
to port pack 160 and thus to connector 660 is the dis- 
cussed in more detail below. Pin outs on connector 660 
are assigned as shown in FIG. 6a with reference to 
Table 3 below. 

TABLE 3 



8 





Signal Assignments for SCSI Connector 660 


Fin 


Signal 




Number 


Name 


Signal Description 


661 


/REQ 


IT » i in »t 1 Fr\r a DPn/AOIT /lata tmwb* 

ncijusi [or a n£y/AV«h uaul uonsrer 






handshake 


662 


/MSG 


innTcaffs tne message pnase 


663 


/I/O 


Controls trie direction of data movement 


661 




Cr^Cl /lata tine nc«t 

uaia cos reset 


665 


/ACK 


Acknowledge for a REQ/ACK data transfer 






handshake 


666 


/BSY 


Indicates whether SCSI data bos is busy 


667 


GND 


Ground 


668 


/DfiO 


Bit 0 of SCSI data bus 


669 


OND 


Ground 


670 


/DB3 


Bit 3 of SCSI data bus 


671 


/DB5 


Bit 5 of SCSI data bus 


672 


/DB6 


Bit 6 of SCSI data bus 


673 


/DB7 


Bit 7 of SCSI data bus 


674 


GND 


Ground 


675 


/C/D 


Indicates whether control or data is on the 






SCSI bus 


676 


GND 


Ground 


677 


/ATN 


Indicates an attention condition 


679 


/SEL 


Selects a target or an initiator 


6S0 


/DBP 


Parity bit for SCSI data bus 


681 


/DB1 


Bit 1 of SCSI data bus 


682 


/DB2 


Bit 2 of SCSI data bus 


683 


/DB4 


Bit 4 of SCSI data bus 


684 


GND 


Ground 


685 


TPWR 


+5 volts terminator power 
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20 
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30 
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Circuitry of the Diagnostic Tool 

A block diagram of the main unit of diagnostic appa- 
ratus 190 is shown with reference to FIG. 9. Central 
processing unit 901 of diagnostic tool 100 is a 
68HC1 1E9 microcontroller manufactured by Motorola, 
Inc. of Schaumburg, HI. The HC1 1E9 version of the 
microcontroller comprises the following features which 
are useful for implementing certain features of the pre- 
ferred embodiment: 

12 kilobytes of internal programmable read-only 
memory (PROM>, 

512 bytes of internal read-only memory (RAM); 

512 bytes of internal electrically erasable programma- 
ble read-only memory (EEPROM); 

a serial communication intestate with 32 selectable 
baud rates: 

a serial peripheral interface: 

an 8-cbannel, 8-bit analog to digital (A/D) converter; 
and 

an 8-bit pulse accumulator/generator system. 
A detailed description of the M68HC11E9 CPU 901 
used in the preferred embodiment may be found in the 
publication M6%H CI 1 Reference Manual, Revision 1, by 
Motorola, Inc. of Schaumburg, HI. (1990). CPU 901 is 60 
clocked by a 9.8304 MHz crystal which internally di- 
vides to a 2.45676 MHz "machine cycle" timing refer- 
ence for CPU 901 and external devices. CPU 901 is set 
into a "special bootstrap" mode for updating and testing 
its internal EEPROM. During the normal operation of 65 
the preferred embodiment, CPU 901 is run in its ex- 
panded multiplex mode wherein dedicated ports B and 
C on CPU 901 are converted to 16-bit multiplex address 



40 



45 



50 



55 



and 8-bit data lines A/DO through A/D7 and A8 
through A15. 

In addition to the onboard non-volatile memory and 
RAM available to CPU 901, diagnostic base unit 190 
further comprises a 32-kilobit by 8-bit static random 
access memory (SRAM) 902 which is coupled to CPU 
901. Memory 902, in a preferred embodiment, is a 32- 
lalobit by 8-bit SRAM, part No. 60L256 manufactured 
by Motorola, Inc. of Schaumburg, HI. SRAM 902 is for 
storing additional information needed by CPU 901, 
such as a buffer area for various ports and for use as a 
scratch pad memory. As is shown in FIG. 9, pulse accu- 
mulator circuitry of CPU 901 is coupled to port pack 
connector 910 via port A 901c to provide communica- 
tion with various circuitry contained in the peripheral 
port pack 160 as shown in FIG. 8 via connector 810. 
Port A 901a doubles as the pulse accumulator/timer 
circuit and I/O lines for CPU 901. These lines provide 
the input capture and output capture compare functions 
for time signal measurements and generation to and 
from base unit 190. Port A 901a is used for handling the 
UUT's input/output (I/O) signals. PAL's 980 provide 
the necessary address decoding to access SRAM 902. 

Further, port E 901e of CPU 901 is coupled to con- 
nector 910 which is used as an analog to digital (A/D) 
port. Port E 901e is used for measuring various voltages 
from the UUT including the battery and the power 
supply on the UUT. These are measured via channels 1, 
2, 3, 4, and 5 of the A/D converter internal to CPU 901 
coupled to port E 901e. Certain input signals are fed 
through voltage divider circuits and then through high 
impedance op amps. The divider and op amp circuit are 
used to measure voltages up to twice the +5 volt refer- 
ence provided at VJuysuch as for the sound connections 
and certain serial port lines. This increases the gain of 
certain input signals prior to digitizing by CPU 901. The 
low voltage reference Vlh for the A/D converter is 
tied to ground. 

Address/data lines 901e of CPU 901 are coupled to 
two port replacement units 920 and 930. which, in the 
CPU 901's expanded mode, allow additional ports to be 
made available to CPU 901. When operating CPU 901 
in the expanded mode ports B and C of the 68HC11 
processor are reconfigured to operate as multiplexed 
address/data lines A/DO through A/D7 and A8 
through A1S. Of course, it will be appreciated by one 
skilled in the art, that other microcontrollers which do 
not operate in this manner may not need port replace- 
ment units such as 920 and 930. Port replacement unit A 
920 is used for controlling keypad 120 and LCD display 
110 of diagnostic base unit 190. Address/data lines of 
port 901c are further coupled to a second port replace- 
ment unit 930. 930 is coupled to a SCSI interface 940 
which is a standard 53C80 SCSI interface integrated 
circuit manufactured by NCR Corporation for provid- 
ing SCSI transfers to and from port pack 160 as shown 
in FIG. 1. 

Address/data lines 903 of CPU 901 are also coupled 
to ROM pack connectors 950 and 960 which are stan- 
dard 40-pin CN215J040-G/O female connectors manu- 
factured by Fujitsu Corporation. These provide the 
coupling between the ROM packs 140 and 150 and 
CPU 901 for hardware specific diagnostics. Communi- 
cation with ROM packs 140 and 150 is provided via 
port replacement unit B 930 and PAL's 970. PAL's 970 
are also coupled to remote port 430 for serial communi- 
cations to perform remote diagnosis of peripherals or 
computers over telephone lines via modem. 



08/15/2003, EAST Version: 1.04.0000 



5,357,519 

9 10 

When CPU 901 is operated in its multiplexed or ex- with SCSI interface 940, and ROM packs 140 and 150. 
panded mode, general purpose I/O ports B and C of It is also used for providing control to a UUT serial port 
CPU 901 configured to operate as multiplexed address- 90W and for communication over remote port 430. It 
/data lines. Port replacement unit A 920 is coupled to can be appreciated by one skilled in the art, however, 
the address/data multiplex lines of port 901c on CPU 5 that any number of computer systems and/or ports may 
901 in order to provide communication between keypad be used depending on the configuration of the port 
120, LCD display 110 and unit 190. Address lines A8 pack, such as 160, which is coupled to diagnostic base 
through All are processed through a PAL to provide unit 190. Port C 930c of port replacement unit B 930 
the necessary decoding to generate a chip select signal provides communication with SCSI controller 940, 
(/CS) in order to indicate which of the two port re- 10 which is, 'in- turn, coupled to port pack 160 via connect 
placement units is being accessed. Port replacement unit tat 910. This provides communication with SCSI de- 
920 enables communication between keypad 120, LCD vices coupled to a port such as 660 shown in FIG. 6. 
display 110, and CPU 901. Port B 920A of port replace- Port C 930c of port replacement unit B 930 acts as a 
ment unit 920 is used for communication with LCD bidirectional interface to controller chip 940, but also 
display 110, except for 3 bits of port B which are used 15 provides a serial communications port selector line for 
for controlling various functions in port pack 160. The communication with remote port 430. In addition, a 
4 most significant bite of the control information passed sleep select pin (/TIRED) is coupled to port C which is 
through port B are used for controlling display 110. In used for putting diagnostic apparatus 100 into a mode in 
the preferred embodiment, display 110 is an which the minimum power is consumed (known as a 
LM2433A4C16B dot matrix 4 line by 16 character liq- 20 "sleep" mode). Power consumption is minimized by 
irid crystal display module available from Densitron deactivating the display, and stopping execution of all 
International Corporation. Display 110 requires eight functions except monitoring keyboard interrupts in a 
bits of information to generate a character. 4 bits (a manner well-known to those skilled in the art. SCSI 
nibble) of each datum contained in the control register data is memory mapped into RAM area 902 providing 
of port B is written individually to the memory mapped 25 bidirectional data transfers between port replacement 
region for LCD display 110 at a time. The high order unit B 930 and SCSI communications chip 940 for read- 
nibble data is first sent for the display, followed by the ing and writing data between UUTs. Signals for con- 
low order nibble data in sequential order. When LCD trolling SCSI transfers between communications chip 
display 110 receives the high nibble of an instruction or 940 and port replacement unit 930 are well-known to 
display character, it latches the data until it receives the 30 those skilled in the art and are used for SCSI transfers 
low order nibble data and then the data (character or via 940 in the preferred embodiment One function 
instruction) becomes available for display. provided by the preferred embodiment is the use of a 

The remaining four bits of the port B control register software-controllable SCSI termination of the UUT for 
920* of port replacement unit A 920 are used for various simulating the presence of device(s) coupled to the 
control functions. Bit 0 (the least significant bit) of port 35 UUT. This termination is activated by setting a bit in a 
B 920c* is used to control the command/display mode control register of port B. Diagnostic base unit~190 can' 
for LCD display 110. Bit 1 is used to control the read also simulate a SCSI devic^!o^Wf^l^a0J|he 
and write direction of LCD display 110. The two re- presence of partitions, and file allocation tables for per- 
maining bits of port B 920b are used for controlling the forming^jther'types of testing. 

UUT. Bit 2 is used to initiate a "power on" sequence in 40 - Port B 9306 of port replacement unit B 930 is used as 
the Macintosh II brand family of computers available general purpose port for external ROM and RAM page 
from Apple Computer, Inc. of Cupertino, Calif, via port control, as well as ROM pack and serial EEPROM 
pack unit 160 as discussed with reference to Table 1 selectors. Address lines A 12 through A1S on port 901c 
above. Bit 3 of port B 9206 of port replacement unit A of CPU 901 are remapped using PAL's 970 to provide 
920 is used to supply power to port pack connector 910 45 the appropriate memory mapping in CPU 901's random 
during data transfers as a means of prolonging the bat- access memory. Each individual ROM pack is selected 
tery life of diagnostic tool 100. via a select bit contained within the control register for 

Port C 920c of port replacement unit A 920 is used for the ROM packs. This selects which connector 950 or 
receiving information from keypad 120. Keypad 120, in 960 is accessed for data, to access tests to residing in 
one embodiment, is a 15-key 9-pin custom silicon rubber 50 ROM pack 140 or ROM pack 150. Each ROM pack 
keypad. 120 may be one of any number of keypads such as 140 or 150 may individually contain hardware 
which are commercially available. The five most signif- specific tests. 

icant bits of the keypad memory map register are used Diagnostic base unit 190 lastly comprises a serial 
for receiving data from keypad 120 in a manner well- communication port which is coupled to port D 901c/ of 
known by those skilled in the art. The three least signifi- 55 CPU 901. Three separate serial communication lines are 
cant bits of the control register are used for enabling- provided through port 901d which are activated by two 
/disabling the columns on the keypad for receiving data lines on port B 930/3 of port replacement unit 930. When 
input from keypad 120. Key 921 on keypad 120 (the "*" both of the control bits are cleared, the serial communi- 
or "command" key) is used for generating an interrupt cations port 90W is put into a loop back test mode, 
request to CPU 901 that a command is being issued 60 Either one of these signals being activated enables one 
through keypad 120. This is coupled to the maskable of two sets of serial communication transmit and re- 
interrupt line of CPU 901 to indicate the issuance of a ceive lines. Both bits being set enables a third set of 
command. transmit and receive lines. Port D 901c/ of CPU 901 is 

A second port replacement unit B 930 shown in FIG. coupled through an RS-232 driver receiver chip (Mo- 
9 is used for providing communication with ROM 65 torola part No. MC145407-not shown) which is then 
packs 140 and 150, and port pack 160 in the preferred coupled to port pack connector 910. The third set of 
embodiment. When port replacement B 930 is selected serial transmit and receive lines are used for communi- 
via the chip select signal, it is used for communicating cation over remote port 430 for remote UUT testing. 
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The first set of transmit and receive lines are the pri- diagnostic base; unit 190 for performing various tasks, 

mary communication means by which the preferred Communication via ports 610 and 620 is described in 

embodiment communicates with software diagnostics more detail with reference to Hardware Guide at pages 

embedded in certain types of computer systems, such as 287-326. 

the Macintosh brand family of computers. These em- 5 Serial and SCSI communication is performed with 
bedded software diagnostics are collectively known as the UUT through connectors 630, 640, and 660 is ac- 
the "Test Manager." The second set of transmit and complished via the remaining lines 1070 coupled to 
receive lines are used for the loop back communication connector 810. Sampling of voltages on these connec- 
port signals for serial printer ports used in the Macin- tors is also provided in a similar manner as discussed 
tosh SE and Macintosh II brand family of personal 10 with regard to connectors 610 and 620 via analog 
computers. MUX'S 1030 across lines 1040. Sound capabilities of the 
Standard RS-232 signals are used by diagnostic de- UUT> m certain systems, may also be tested in this man- 
vice 190 for communication with UUT's. However, ner . other analog voltages, as may be appreciated by 
computer systems such as the Macintosh family of per- one skilled m the art, may be sampled in similar man- 
sonal computers are capable of using EIA RS-422 hard- IS ners 
ware protocols which are currently unused by the com- 
munications ports directly. The unused lines of the Software Controllable SCSI Bus Termination 
RS-422 lines are selectively sampled using the A/D A detailed description of ^ controllable 
muluplexers on port pack 160 wmch as discussed in SCSI termination 1010 of ^ ferred em . 
more detail below, are connected to port g 901c on CPU 20 will now be ^ aj ^ mx plG 
901 via port pack connector 910. A detailed description „ The ^ , ed from 810 10 SCSI ^ 

ttZZS^SXZ » ™ «»** ^ 1010 for providing the 



to diagnostic base unit 190 in one embodiment will now 
be discussed in more detail with reference to FIG. 10 



25 



bus termination. Five volts is received on line 1121 from 
pin 685 on connector 660 to circuitry 1010. One signal 
Circuitry of the Port Pack " line, REG3 1060 from base unit 190, is provided which 

A block diagram of peripheral port pack 160 which f^ 65 t ™£? n - ^ Mesll0 ° 
may be used in one embodiment of the present invention fr ? m connecto ,, r ^ °f e ""^ t0 *"» } reslsto " 
is shown and discussed with reference to FIG. 10. As of P«*» 1110, and resistor pack 1110 is coupled 

was discussed with reference to FIG. 6 above, port 30 * ** ™ *od« in either of diode packs 1111, 

pack 160 comprises a series of pens 610 through 660 1112 ' ° r P" f ? ° f ^ *" dK ? eS m dwde 
which are coupled via connector 810 to diagnostic base Packs 1111, 1112 and 1113 are tied together and con- 
unit 190 in order to test specific types of UUT's. Periph- nected to out P ut ^ 1114 of ^ low out P° sl " 
eral port pack 160 has an FCN215Q080-G/O 80-pin Uve adjustable voltage regulator 1115. Voltage from 
male connector 810 manufactured by Fujitsu, Inc. 35 1117 fa b y **ktors "22 (121ca)and 1123 (249<u) 
which mates with connector 910 on base unit 190. A which 2X6 coupled to ground on 1128 on 1115 and the 
control register of CPU 901 is used to select, via analog output 1114 through a series of capacitors (1126 and 
multiplexer 1030 shown in FIG. 10, analog signal chan- 1172 311(1 1124 ) tied t0 ground 1125. The input 1116 of 
nels for measurement Analog multiplexers 1030 are device 1115 is coupled to the drain 1118 of a dual P- 
controlled via analog line selectors 1050 which are 40 channel enhancement MOS-FET 1117. The source 
coupled to port A 901a of CPU 901. Another signal line 1120 of 1117 " coupled to the termination power line 
coupled to port A 901a on CPU 901 is used for enabling 1121 (which carries + 5 volts) of the UUT (pin 685 on 
SCSI termination. This is coupled via line 1060 from connector 660). Gate 1119 of MOS-FET 1117 is cou- 
connector 810 to termination circuitry 1010. pkd to signal line 1060 coupled to a register in base unit 

In the preferred embodiment, analog multiplexers 45 I s0 received from for activating SCSI bus termination. 
1030 comprise four 74HC4051's available from Motor- When this bit is set to a logic 0, a negative voltage is 
ola, Inc. The selection of each analog MUX 1030 ena- created at gate 1119 of 1117 effectively sourcing +5 
bles any or all of lines 1040 for conversion and measure- vo l te From pin 685 (termination power) to 1116 on 
ment of voltage, values by base unit 190. Also, SCSI UiS. 1115 steps down the voltage to 3.8 volts which is 
and serial data lines 1070 from port pack 160 are cou- 50 supplied to diode packs 1111, 1112, and 1113. Diode 
pled to connector 810 for communication with the serial packs 1111, 1112, and 1113 drop the voltage down an- 
and SCSI circuitry within base unit 190. An additional other one volt to provide 2.8 volts to resistor pack 1110. 
feature provided by port pack 160 is UTON select line The 2.8 volts with 250 mA limiting resistors is provided 
1021. When activated, this line activates power to cer- to the remaining SCSI lines 1100 and meets the proper 
tain types of UUTs. UTON select line 1021 is coupled 55 voltage and current specifications for SCSI termination 
to circuitry 1020 to momentarily ground pins 612 and of the bus. 

614 on connectors 610 and 620 in order to initiate a On the other hand, when a logic "1" is present on 
remote power up of the UUT as discussed with refer- signal line 1060, the voltage at gate 1119 of 1117 is 
ence to Table 1 above. For other types of UUTs not equalized, and thus removing SCSI bus termination 
having such a design, the user must activate power 60 from SCSI signal lines 1100. No voltage is provided 
manually. from drain 1118 of device 1117 to 1116. Each of the 

For sampling various voltage levels on connectors resistors in resistor pack 1110 appears as an individual 
610 and 620 coupled to the UUT, pins 611 and 614 are open circuit to SCSI connector 660. SCSI termination is 
coupled through analog multiplexers 1030 to connector thus effectively removed. In summary, an active signal 
810. In addition, for communicating with the UUT, 65 over line 1060 causes 1010 to deactivate SCSI bus termi- 
connectors 610 and 620 are coupled to lines 1070 and nation on lines 1100, and a logic 0 received over line 
then to connector 810. Communication is thereby pro- 1060 causes 1010 to activate SCSI bus termination on 
vided between the UUT via connectors 610 and 620 and lines 1100. 
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Twine Utrpc test re 1 u i res one cable to be connected from a UUT to 

8 port 610 or 620. 
The testing of UUTs coupled to diagnostic tool 100 

via port pack 160 in the preferred embodiment is ac- SCSI Termination Check 
complished via a sequence of routines embedded in 5 This test checks the SCSI lines to see if a good termi- 

ROM packs 140 and 150 which perform certain tests nation exists on the bus. This test runs on all Macintosh 

embedded in those ROM packs, or causes accesses to brand personal computers. This test has pass/fail only, 

built-in diagnostics contained within the UUT. In the This test requires a SCSI cable to be connected from 

Macintosh family of personal computers, a series of port 660 to the UUT. 
routines known as the 'Test Manager" is available in io 

the system ROM of each computer. On a system which SCSI Termination Power 

is not even able to power up and complete bootstrap ^ test measure s the termination voltage off the 

miuahzataon, Uus program will be unavailable. There- SCSI bus ^ valuc can from 0 .0 volts to 5.0 

SuSS, i° W " " P^orm certain T volts. This test runs on all members of the Macintosh 

diagnostics such as testing a power on" battery on the is u j i _ « -i i.v u i 

motherboard, testing voltage levels on certain signal ^ f ^ ™ y 
lines, determining whether tLre is SCSI tenninationTor ™ °^f r <*»P*» ha ™g * SCSI connector similar to 
measuring the voltage of SCSI termination. A summary ^ has no P 385 ^ 11 ** t f B ^ 

of these tests is set forth below. Each of these low level voltage ^ a message stating what range of values 
tests is written in 68HC11 assembly language for CPU 20 a functional terminator (usually >4.5 volts). 

901 in the preferred embodiment but may be written in ^ test a SCSI <* Ue to <* connected from 

high level languages such as the "C" or Pascal pro- connector 660 to the UUT. 
gramming language in alternative embodiments. These Termination [On/Off] 

tests are performed without entry into the diagnostic 

program by measuring voltages available on the various 25 function turns on (or off depending on the previ- 

connectors. etc. which are coupled to tool 100 and a ous me internal termination power of the SCSI 

UUT. These tests are as follows: bus in diagnostic tool 100. This function runs on all 

members of the Macintosh brand personal computer 

Tests that Do Not Require the Test Manager to family. This function has no pass/fail. It displays the 

Function ^ termination condition as on or off on the screen. This 

Power Supply (PowrS) function requires the SCSI cable to be connected to 

. . . lt . , - connector 660 and the UUT. 

This text measures the voltage at the power supply of 

the UUT. The value can range from 0.0 volts to 5.5 SCSI Reset 

volts. This test runs on UUTs in the Macintosh brand , , „„„ T , . 

of personal computers. This test has no pass/fail. It 35 V™ funCb0n forces f ^ SCSI reset on the bus. 

displays the voltage with a message stating what range V"* {unc * an °° fl^l type hard drives. This 

of values indicates a functional power supply (usually function has no pass/fail. This function requires a SCSI 

>4.5 volts). This test requires a cable to be connected 031)16 to 1x5 connected to connector 660 and the drive, 

to a UUT and either port 610 or 620. SCSI Bus Scan 

40 

Battery Voltage (Batt.) This test scans the SCSI bus looking for hard drives. 

This test measure the battery voltage off the ADB K builds a table of any drives it finds and allows the user 

cable. The value can range from 0.0 volts to 10.0 volts. to obtain information about each drive such as drive 

This test runs on Macintosh II motherboard and IIx type manufacturer and size. This test runs on all SCSI 

brand computers. This test has no pass/fail. It displays 45 1 W e bard drives. This test has no pass/fail. This test 

the voltage of the battery with a message stating what requires the SCSI cable to be connected to connector 

range values indicates a functional power supply (usu- 660 and the SCSI bus being tested, 

ally >6.5 volte). This test requires a cable to be con- ~„. , - _ . lW .„> 

nected from a UUT to either port 610 or 620. TeSt Manager Eatrv C™d"> 

„ , ^ „ 50 TbisfunctionenterstheTestManagerontheUUT.lt 

Power Up Voltage (PwUpV) cydes po Wcr ^ ^ ±c SCSI btts to julnp ^ the 

The Macintosh Ilex brand computer uses a trickle Test Manager on the UUT. This function runs on all 
current from the power supply to provide power up machines equipped with a SCSI chip and having a Test 
voltage (which is provided by a battery on the mother- Manager diagnostic program. This function fails only if 
board). This test measures the trickle current off a cable 55 it is not successful in entering the Test Manager. This 
coupled to 610 or 620. The value can range from 0.0 function requires that cables be connected from the 
volts to 10.0 volts. It is very similar to battery voltage. UUT to 660, 610 or 620, and a serial cable for the 
This text has not pass/fail. It displays the voltage with modem to be connected to port 630 or 640. The process 
a message stating what range of values indicates a func- of entering the Test Manager is discussed in more detail 
tional power supply (usually. >4.5 volts). This test re- 60 with reference to FIGS. 12a through 12d. 
quires a cable to be coupled to a UUT and either port _ . _ 

610 or 620. Entering the Test Manager Diagnostic System 

If the system is able to receive system power, how- 
ever, the Test Manager diagnostic program may be 
This function, by imitating the action of pressing the 65 entered in the UUT to perform certain tests at the user's 
soft power on key activates power in the UUT. This choosing using diagnostic tool 100. There are two ways 
function runs on Macintosh II, IIx and Ilex brand per- in which the Test Manager is entered in a Macintosh 
sonal computers. This function has no pass/fail. This brand personal computer using the preferred embodi- 
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ment: by manually initiating a "non-maskable interrupt" present, then 1212 branches to step 1218 to continue the 
(NMI) switch 620 on a Macintosh brand personal com- initialization. If SCSI bus termination is not present, 
puter; or by causing the UUT to enter the Test Manager then process 1200 proceeds to step 1213. 1213 deter- 
by simulating a SCSI device such as a disk drive and mines whether this is the second attempt to terminate 
jumping to the Test Manager. The former option is 5 the SCSI bus, and if it is, step 1213 proceeds to step 1214 
difficult because the NMI switch must be issued within wherein the message "Cannot terminate SCSI (cable 
five to ten seconds after the UUT commences a bootup. problem?), Try manual power on" is displayed to the 
Fairly tight timing constraints must be adhered to in user. Then, process 1200 branches to the exit process at 
order to enter the Test Manager in this manner. In step 1228 shown in FIG. 12d, and process 1200 is rc- 
UUTs which are able to initiate system power and 10 turned from at step 1235. If, however, this is not the 
perform bootstrap initialization from an attached SCSI second attempt to terminate the SCSI bus, then step 
device, the latter method to enter the Test Manager is 1213 proceeds to step 1215 wherein the user is 
preferred. This is discussed in more detail with refer- prompted with the message that "SCSI termination is 
ence to FIGS. 12 through 15. missing," and the user is given the option to either "1) 

FIGS. 12a through 12a* show one process 1200 which 15 Terminate the bus or 2) cancel" the present operation. It 
checks certain basic conditions in the UUT and at- is determined at step 1216 which option the user se- 
tempts to enter the Test Manager. Prior to bootstrap lected. If "cancel" is selected, step 1216 proceeds to step 
initialization from the simulated SCSI device provided 1235 on FIG. V2d and process 1200 is returned from. If, 
by device 100, certain basic conditions need to be estab- however, the "cancel" selectioo was not made, as deter- 
lished and tested for. Various corrective measures are 20 mined at step 1216, then SCSI termination is attempted 
taken to try to enter the Test Manager if entry is not to be activated at step 1217 as shown in FIG. 126. SCSI 
successful on the first attempt. This process is shown in termination is performed, in the manner as discussed 
FIGS. 12a through 12a*. When a UUT is connected to earlier, using soft SCSI termination circuitry 1010 as 
tool 100 for performing diagnostics, process 1200 is shown in FIG. 11. Then, the message "Waiting for 
executed by tool 100 in order to attempt to enter the 25 SCSI block read" is displayed at step 1218, wherein tool 
Test Manager. Process 1200 starts at step 1201, as 100 waits until the UUT attempts to read from the simu- 
shown in FIG. 12a, by displaying to the user at step lated SCSI device over port 660. Tool 100 will cause 
1202 that power-up routine is being initiated in the the UUT to enter fine Test Manager by "feeding" 
UUT. At step 1203, the SCSI bus termination and boot blocks to the UUT at step 1219. This is discussed in 
attempt counters, which are used for multiple attempts 30 more detail with reference to FIG. 13. Tool 100 then 
to terminate the SCSI bus or attempt to initialize the waits three seconds in order for the Test Manager to be 
system, are cleared. The serial modem port 430 on tool entered at step 1220 after the issuance of the entry se- 
100 is initialized at step 1204 in order to prepare the unit quence at step 1219. It is determined at step 1221, 
for communication with a UUT. At step 1205, it is whether the UUT is in the Test Manager. If the UUT is 
determined whether the UUT is already powered up. If 35 not in the Test Manager, then process 1200 proceeds to 
power is present in the UUT, then process 1200 pro- step 1222 in FIG. 12c. If, however, the UUT was in the 
ceeds to step 1221 as shown in FIG. 126. It is deter- Test Manager, then process 1200 proceeds to step 1224 
mined whether the UUT is powered up, in a Macintosh in FIG. 12<£ 

brand computer system, using techniques well-known As shown in FIG. 12c, process 1200 continues at step 
to those skilled in the art by sampling certain lines cou- 40 1222 wherein it is determined whether UUT power was 
pled to either ports 610 or 620 of peripheral port pack on already, or whether the power-on sequence at step 
160. If the UUT is not powered up, as determined at 1206 had to be performed. If power was already on in 
step 1205, then process 1200 proceeds to step 1206 the UUT, then process 1200 proceeds to step 1229 
wherein a power-up is attempted on the UUT using the wherein it is ascertained whether this is the second 
sequence issued over port 610 or 620 on port pack 160 45 attempt to boot the Test Manager in the UUT. If it is the 
for certain models of the Macintosh brand computer. second attempt to boot, then the message "SCSI/serial 
Again, it is determined at step 1207 whether the UUT problem. Try manual entry (press BACK)" is displayed 
has system power, and if it does, then process 1200 at step 1223. If process 1200 activated power in the 
proceeds to step 1212 on FIG. 126. If not, as determined UUT, then step 1222 also proceeds to step 1223 to dis- 
at step 1207, the message "Waiting for power on" is 50 play the message. After the message if step 1223 is dis- 
displayed at step 1208, and process 1200 in FIG. 12a played, the exit process at step 1228 shown in FIG. 12a" 
proceeds. It is then determined, at step 1209, whether is performed, and process 1200 is returned from at step 
the "Back" key has been depressed by the user. This key 1235. If this is not the second boot attempt as deter- 
allows the user to abort from any process currently mined at step 1229, then the message "Waiting for 
executing in tool 100. This is used if the user wishes to 55 power off" is displayed at step 1230, and the UUT is 
escape out of the waiting for power on loop of steps checked via ports 610 and 620 to see whether power is 
1209 and 1210. If the "back" key is depressed, then off in the UUT at step 1231. If it is not, and the "back" 
process 1200 returns from Test Manager entry sequence key was not depressed (causing interruption of process 
1200 at step 1211. If the "back" key has not been de- 1200), then steps 1231 and 1232 are performed repeti- 
pressed as determined at step 1209, then the UUT is 60 tively until it is determined at step 1231 that power is off 
tested again at step 1210 to determine whether system in the system, or the "back" key is depressed. When 
power is present Steps 1209 and 1210 are repetitively power-off is detected in the UUT at step 1231, then 
performed until it is detected that the UUT has pow- process 1200 proceeds back to step 1206 to issue a 
ered up as determined at step 1210. Once power is pres- "Power-on" signal to the UUT as shown in FIG. 12a. If 
ent, step 1210 proceeds to step 1212 in FIG. 126. 65 the "back" key is depressed, as determined at step 1232 
As shown in FIG. 126, process 1200 continues at step (interrupting Test Manager Entry Process 1200), then 
1212 wherein it is determined whether SCSI bus termi- process 1200 is returned from at step 1235 shown in 
nation is present in the UUT. If SCSI bus termination is FIG. 12a". 
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If the UUT was not in the Test Manager as deter- 
mined at step 1221 in FIG. 126, then process 1200 pro- 
ceeds to step 1224 in FIG. 12rf. Step 1224 in FIG. lid 
checks the UUTs timing. This is determined using 
techniques well-known to those skilled in the art by S 
sampling various signals received over the ports on port 
pack connector 160 to see if the UUT is responding 
within defined tolerances. If the timing is bad as deter- 
mined at step 1225, then process 1200 proceeds to step 
1226. If the timing is not bad as determined at step 1225, 10 
then the message "Communications established: CPU is 
in Test Manager mode" is displayed at step 1233, and 
tool 100 waits an additional five seconds for a user 
intervening keypress, at step 1234. If no keypress is 
received, process 1200 returns at step 1235. If, however, 15 
the timing was bad as determined at step 1225, then 
process 1200 proceeds to 1226 to determine whether 
tool 100 activated power in the UUT. If power was on 
already (tool 100 didn't activate the power), then a 
"RESET" command is issued to the UUT at step 1236 20 
and process 1200 continues at step 1221 as shown in 
FIG. 126. If power was activated in the UUT by tool 
100, then the message 'Test Manager OK but timing 
problem found" is displayed at step 1227, and the exit 
process is branched to at step 1228. Then, process 1200 25 
is returned from at step 1235. 

Thus, at the end of process 1200, the UUT should be 
in its Test Manager mode, or the user is prompted with 
various options that be may take in order to perform 
diagnostics on the UUT. The entry into the Test Man- 30 
ager by simulating a SCSI device mentioned with refer- 
ence to step 1219 will now be discussed. 

Entry Into the Test Manager by Simulating a SCSI 

Device 3J 

Entry into the Test Manager is performed by diag- 
nostic toolJLOO by simulating a SCSI device to the UUT. 
This is accomplished by sensing signals received 

/through connector 660 transmitted by the UUT. When 
the appropriate SCSI initialization signals are received 40 
through port pack 160 from a UUT coupled to connec- 

r tpr_660, diagnostic tool 100 issues response signals 
thr ough*c onnector - 660-to the'UUTto cause the system'' 
to iumVttTthe'Test Manager^It.performs .tnis^bv simu - 
latiBg VSgSI'dev ic'e T snch as'a'disk^drive-using^a^driver ^45 
de^nptorJmapi(0DM)Ta?dlplxtition»m 
is'S^iSl'bTcerta^ 

-entries are shown in more detail in FIGS. 14 and 15. As 
is well-known to those skilled in the art, a computer 
system having a SCSI interface, such as a UUTWobes 50 
the SCSI bus to determine if SCSI devk^^e^esent' 
Each SCSI device identifies itself with an identification 
number. This is known as the arbitration phase. Once, 
I P's hav ebe e nsanK riedi|hy«the UUT, selection of a 
devic^nUy^D^accompuInM. This is known as the se- 55 
lection phase. After arbitration and selection, the UUT 
can issue a command (such as a read or a write) and the ~ 
device will respond with data. The preferred embodi- 
ment senses the issuance of the arbrtra'tionand selection ' 
signals, and"simulates* r a*-SeSI -device"with an ID =6; 60 
whieh*is^the^defalUt»high^^ 

besidesitie UUT in a'MaSintosH brand computer. Other 
responses to probes by the UUT are now discussed. 
These are performed, as is well-known to those skilled 
in the art, by sensing the arbitration, selection, and com- 65 
mand signals sent by the UUT, and device 100 responds 
in a manner expected from a SCSI device. The signals 
issued to the UUT will now be discussed. 



The SCSI Test Manager entry process performed by 
the*UUT il^'oW T as Y300'ip FIG". 13 (referred to in step 
1219^f'process' 1200). Process 1300 is performed by a 
UUT when allowed to continue to perform bootstrap 
initialization and has a SCSI device coupled to one of its 
ports through port 660. Process 1300 starts at step 1301 
wherein, at step 1302, a first available SCSI device on 
the bus is selected that has an ID = 6 (this is the highest 
priority SCSI device in a Macintosh brand computer). 
When the UUT requests an access to the SCSI device 



ISOrThe format of data responsive to requests issued by 
the UUT is shown in FIG. 14 and is shown in more 
detail in FIGS. 14 and 15. Aj^te ^^^the JjUT^ ill 
attempt to read th e &5P^o 1 ^es^t i DiSir ff 'of this 
simulate^^e^c?*oy , ^^5Sg* , ^ea^^omm^ds through 
port'fifiO't&'tooMOO. BIock^l40ri^K5wB^th^feT- 

map^^^ ^^^^^ ^iSateT^C^p^'tion'. The 
UUT attempts, arsHep"1304, to look for a driver descrip- 
tof1n?p g suc1r^^ (this 
indicates that the SCSI device has been formatted). This - 
is indicated as field 1501 in FIG. 15. Upon receiving the 
address for the first 256\>y\cs of block 0 of the unit with 
ID==6, diagnostic tool 100 transmits DDM 1401 onto 
the"SCSI bus. Driver descriptor map 1401 comprises 
two portions, 1401a and 14016. 1401 a contains "real 
data" which resides in non-volatile memory of tool 100 
and is transmitted to the requesting UUT. The remain- 
ing portion 14016 of the data is zero-filled and transmit- 
ted to the UUT through port 660 byte-by-byte from a 
register in tool 100. The remaining blocks shown in 
FIG. 14: 14026, 14036, 14046, and 14056 are similarly 
zero-filled and transmitted to the UUT. The remaining 
"real " portions of driver descriptor map 1401a is 
shown in FIG. 15. Driver descriptor map 1401a indi- 
cates the size in blocks of the device in field 1502 (a one 
word field) and the number of blocks on the device in 
field 1503 (a 32-bit longword). Blocks are 512 bytes 
long, in a preferred embodiment. Field 1504 indicates 
the device type (a one for disk drive), 1505 has the 
device ID type (one). Field 1506 also contains a one, in 
the preferred embodiment, a value expected by Macin- 
tosh brand UUTs. The number of driver descriptors is 
contained in field 1507. In this example, there is only 
one. The driver descriptor starts at field 1508. The first 
block of the driver resides at block four as indicated by 
field 1508 (a 32-bit longword), and the driver size is 
exactly one block long as indicated by field 1509. 
Lastly, the driver type is of type 1, which is contained 
in field 1510, in the Macintosh brand family of personal 
computers. After" the driver descriptor map is read at 
step 1304, step"iJUsTfeadrihe' p^seudo^aevic« _ driver of 
the simulated SCSI device at block 4, shown as 1405 in' 
FIG. 14. The format of blocks 1402 through 1405 are 
discussed with reference to FIG. 16. 

Partition map entries, such as 1402, 1403, 1404, or 
1405 are one-block entries containing information about 
the SCSI partitions which are being accessed The ) 
pseudodevice drive ? of the p rtferred embod iment re- / 
sides inonejBr^^^p'arUtibn map entries, and'isshown 
aTl405 T uTFlS-714: Each of the partition map entries has 
a specific format, which is well-known to those skilled 
in the art, and is set forth in Inside Macintosh, Volume V 
available from Addison- Wesley at pages V-576 through 
V-582. Because the actual data contained within fields 
in blocks such as 1402 through 1405 is well-known to 
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those skilled in the art, a detailed discussion of that will ' 
not be set forth here. Each of the blocks 1402 through 
1405 contains a first portion such as 1402a through 
1405a, which contains real data in order to conserve 
space in the ROM of the preferred embodiment. The 5 
remaining portions such as 14026 through 14056 contain 
dummy data which is transferred to the UUT when 
request for the remainder of the block is made by the 
UUT. In each of the partition map entries 1402 through 
1405, the actual portion read in by the UUT, 1402a 10 
through 1405a, is 64 bytes in length. The remaining 
portions 14026 through 14056 are padded with zeros. 
The partition map entries are then read by the UUT. At 
step 1306, the partition map 1402 for the operating sys- 
tem is read. Once this is done, the partition map entry IS 
for the pseudo partition is read at step 1307. Then, the 
partition map entry 1404 for the driver is read in at step 

1308. This gives the system the address at which to start 
to execute the driver contained in 1405. Then, at step 

1309, the partition map entry for the operating system 20 
1402 is read again. At step 1310, the driver residing at 
the location indicated by 1404 is called to install itself 
and the driver causes a jump to the Test Manager to 
occur. Once process 1300 is complete, at step 1311, the 
Test Manager is running in the UUT, which can now be 25 
accessed and communicated with by diagnostic tool 
100. 

In summary, diagnostic tool 100, in one embodiment, ' 
of the invention, simulates a SCSI device with an ID =6 
for a"Wacintosh brand personal computer. A series of / 



requests is made to the device to read various informa- 
tion off a simulate d SCSI device. Blocks af'e refurned 
fronfTmTam^ateaTlevic^as sho"wff*uV"FIGr'l* and' 
^described with reference to FIG.. 13* and the diagnostic' 
device, 100 returns blocks which are expected by the 
UUT. Slocks are fed to the UUT in the following order: 
1401, 1405, 1402, 1403, and 1402. As a last step, the 
device driver residing in block 1405 is called to execute 
itself thus causing a jump to occur to the Test Manager 
which resides in the UUT system ROM. 

Once entry into the Test Manager of the UUT has 
been performed, various tests within the Test Manager 
may be accessed and executed. It can be appreciated by 
one skilled in the art that other architectures possessing 
similar test routines may be accessed in a similar man- 
ner. This will allow entry and testing in an automated 
fashion by diagnostic apparatus 100. The commands set 
forth in Table 4 are provided for execution of the Test 
Manager remotely via a coupling with the UUT to 
serial port 640 on port pack 160. Each command is 
preceded by a "*" which indicates that a command is 
following on serial port 640. When a UUT b activated ' 
and the Test Manager is entered, in one embodiment, ' 
tffe^ai^ft^of the .UUT defaults to a 9600 baud con? 
figuration-and expects commands to W received via 
serial port 640 coupled to the serial port of the UUT. 
Responses to tests requested by diagnostic apparatus 
100 are also provided across the serial port Specific 
commands are summarized as follows: 

TABLE 4 



UUT 

Initiating Command Response Command Name Description 



•S 



•L xx xx xx xx 



•Bxxxx 



•Dxx 



*S Stop initial input 
message and Start 
UUT ROM 
Monitor 



•L Load address 



•B Byte count 



*D Download data 



*C xx xx xx xx *C Checksum data 



*C xx xx xx xx *G Go . . . (execute) 



•O XX XX XX XX 



•1 XX XX 



'O O = low or bottom 
RAM test address 



•1 1 = high or top 



This command is the "handshake" that 
initinlf 7 ^ the UUT ROM monitor to accept 
test commands. It also silences the UUT 
(if the UUT sends out a repeating error 
message upon failure or if the ROM 
monitor has been invoked). 
This command is followed by 4 bytes that 
specify the address where the UUT will 
start loading (or downloading) data into 
RAM Response indicates that the UUT 
received the valid command (handshake) 
Can be used to load tests into the UUT. 
This command is followed by 2 bytes that 
specify the number of bytes to be 
downloaded. (*L must precede this 
command). Response indicates UUT 
received the valid comman d ( handshake) 
This command is followed by xx xx (2 hex) 
bytes as specified by the *B command. 
(*L & *B must precede this command). 
Response indicates UUT received valid 
command Qi&ndshake). 
This command requests memory range 
checksum specified by starting location 
and number of bytes (via *L and *B 
respectively). Returns checksum followed 
by *C. Must be used with *L and *B. 
This command is followed by 4 hex bytes 
that specify the address where the UUT 
win start running a program. (To run a 
downloaded program, *L, *B, and *D must 
precede this command). Response 
indicates UUT received the valid command 
(handshake). 

This command is followed by 4 hex bytes 
that specify the address where the UUT 
will start running a RAM test (A 
pointer). Response indicates UUT 
received the valid command (handshake) 
This command is followed by 4 hex bytes 
that specify the address where the UUT 
will start running a RAM test (A 
pointer). Response indicates UUT 
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TABLE 4-continued 



UUT 

Initiating Command Response Conmand Name Description 



•2rr 



*3 rr xx xx xx xx 



•2 Read CPU 
register 



•3 Write CPU 
register 
Registers: 
D0-D7 SP 
A0-A6 SR 

•4 Q ear UUT error 
registers. (e.g., 
D6.L & D7.W) 

•5 Re-enter ROM 
monitor 



•A A SCn mode 



•H Hex mode 



*R xx xx xx xx xx xx *R Result request 



•Mxx. 



*M Memory dump 



*E Echo 



•I Initialize 



*T tt tt pp pp oo oo »T ROM-resident 
Test request 



received the valid command (handshake). 
Requests CPU register data 
specified by rr. Response returns 
32-bit register information from 
the UUT CPU register, rr. The 
register dump is followed by *2 to 
indicate the end of transmission. 
Writes 32-bit value to register specified 
by rr. 

Example: *3D301F9AB35«3 
•2SP000E9S2 , 2 

Underlined section returned by Test 
Manager) 

Clears the error storage registers on 
the unit under test. Response indicates 
UUT received the valid command 
(handshake). 

Re-starts ROM monitor entry and re-calls 
generic header (e.g,, 
•APPLE'xxxxxxxxxxxx'l*). Response 
indicates UUT received the valid command 
(handshake). 

Sets ASCII character mode. Sends and 
receives ASCII data. Response indicates 
UUT received the valid command 
(handshake). 

Sets hex character mode. Sends and 
receives hex data. Response indicates 
UUt receives the valid command 
(handshake). 

Requests current status or test results. 
Response returns a 12-character result 
code that specifics the current error 
status. 

Requests memory data specified by *L and 
•B (*L and *B must precede this 
command). Response returns memory 
information as specified by the *L and *B 
commands. The memory dump is 
followed by *M to indicate the end of 
transmission. 

Requests the UUT to echo externally 
transmitted characters back to the 
external device. Response indicates UUT 
received the valid command (handshake). 
Requests the UUT to re-initialize itself. 
This terminates serial communications. 
(Re-boot). 

Requests the UUT ROM test to be run. 
This command is followed by 8 hex bytes; 
"tt tt" is the "pass count" (or number of 
tunes test is to be run); "oo oo oo oo" is 
the option word. Response indicates UUT 
received the valid command (handshake). 
Examples of ROM Test number (tt tt) 
activities: 

0000 - Size Memory 

0001 - DataBus Test 

0002 - Mod3Test 

0003 - Addrline Test 

0004 - ROMTest 

0005 - Rev3ModTest 

0006 ■ StattUpROMTest 



An additional feature provided by the Test Manager 
is the ability to download specific tests into the Test 
Manager. This is performed using the "*D" command 
and such tests may be executed by typing is the "*G" 60 
command with the address of the test loaded using the 
"*D" command.. The last command in any user-speci- 
fied test using "*D" must jump back to the starting 
address of the Test Manager to provide the appropriate 
response to diagnostic tool 100. It can be appreciated by 65 
one skilled in the art that a variety of entries into sys- 
tem-specific test functions such as the ones provided 
above may be performed. 



Tests Requiring the Test Manager 

Most of the tests run on diagnostic tool 100 require 
the UUT to be in the Test Manager. This requires the 
machine to have a limited amount of functionality. Most 
of these tests download a piece of code into the UUT to 
run in the native environment If the user attempts to 
run one of these tests without being, in the Test Man- 
ager, he will be given a prompt to enter the Test Man- 
ager by diagnostic tool 100. In order to enter the Test 
Manager automatically, each test requires that the UUT 
be coupled to ports 660 and 610 or 620 using appropri- 
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ate cables. Also, tool 100 must be coupled to the UUT _ ntlw _ /f ,, 1JT1 ^ 

through port 630 using a serial cable to communicate SWIM/TWM Test (SWIM) 

with the Test Manager. This test determines if the CPU has an IWM or a 

t>/iw i «... SWIM (floppy disk controller chips) connected and 

ROM Checksum (ROMck) 5 then tries to imtialize the chip. This test gives pass or fafl 

This test checksums all of the ROM's in the CPU (if only. This test can only detect catastrophic failures in 

more than one exists). This test will not identify individ- the IWM/SWTM. The floppy drive tests provide a 

ual ROM failures. This test fails if the checksum does more comprehensive test of die chip. 



not match the one stored in the ROM, otherwise it 
passes. 10 



FPU Test (FPU) 



ram « n? »« - This test verifies that the FPU chip (floating point 

RAM Size (KAMsz) math co-processor) functions. This test runs on Macin- 

This test determines the size of the RAM in the CPU. tosh II, IIx, Ilex brand family of personal computers. 

The test finds the largest SIMM in the bank and uses This test gives pass or fail only, 
that to determine the size. For example, if the test finds 15 

three 256K SIMM's and one 1 Meg SIMM, it will size Sound Test ( Sound ) 

the machine to 4 Megs. This test has no pass or fail. It This test verifies that the sound chip registers func- 

reports the size of memory it finds and indicates if it tion and that data can be read from and written to the 

thinks the memory is mis configured (a system where the chip. This test also measure the sound out for volume 

largest SIMM's are in bank A instead on bank B) or bad 20 and frequency. This test gives pass or fail only. 

(which may just be mismatched (a system which has /»i-»m 

different size SIMM's in the same bank)). ADB Test (ADB} 

This test verifies that the ADB (mouse and keyboard) 

Address Test (Addr.) transceivers, the portions of the VIA that control ADB, 

This test checks the address lines of the CPU. It de- 25 the ADB line and the ADB port is functional. This test 

termines if the lines are functioning properly. This test gives pass or fail only. This test requires that both ADB 

has pass or fail only. cables be connected from the UUT to ports 610 and 620. 

Databus Test (Data) Video Card Test (Video) 

This test checks the data lines of the CPU. It deter- 30 This test determines what video cards are in what 

mines if the lines are functioning properly. This test slots and builds a menu for the user. The user can select 

graphically shows catastrophic errors and missing which card he wants to test. The test will then test the 

SIMM's. RAM on the selected video card. This test runs on the 

ctmvp t fiTKTKA \ Macintosh II, IIx, and Hex brand family of personal 

SIMM s Test (SIMMs) 3J computerS- This test gives graphic representation of 

This test uses the results from RAM Size to read and which SIMM's are bad or fails the card if the soldered 

write RAM to determine if it is good. This test graphi- SIMM's are defective, 

cally shows catastrophic errors, missing SIMM's and _ _ . _ . . 

individual bad SIMM's. Floppy Dnve Test (Dnve) 

40 This test determines what floppy drives are in what 

VIA Test (VIA) ports and builds a menu for the user. The user can select 

This test checks the VIA's (Versatile Interface Adap- which drive he wants to test. It then tests the ability of 

tors or Peripheral Controller Chips) for functionality. the drive to read, write, and seek. This test gives pass or 

This test gives pass or fail only. fail only. 

Clock Test (Clock) 45 Power Off CPU 

This test checks the UUT real time clock chip for This test shuts off power to the CPU. This test funs 
functionality. This test gives pass or fail only. on Macintosh II, IIx, and Ilex brand family of personal 

computers. 

Parameter RAM Test (P/RAM) 50 ^ invention for diagnosis for computer sys- 

This test verifies that the PRAM (parameter RAM terns has been described. Although the present inven- 
which controls data, and mouse information) can be tion has been described particularly with reference to 
read from and written to. This test gives pass or fail FIGS. 1 through 15, it will be apparent to one skilled in 
only. NOTE: There are two modes of operation for this the art, however, that the present invention has utility 
test. One mode saves and restores the contents of 55 far exceeding that disclosed in the figures. It is contem- 
PRAM (parameter RAM of the UUT), and the other plated that many changes and modifications may be 
mode clears out all of PRAM. made, by one of ordinary skill in the art, without depart- 

_ _ _ ing from the spirit and scope of the present invention as 

SCC Test (SCQ disclosed above. 

This test verifies that the SCC chip functions in all 60 What is claimed is: 
modes and that the serial bus can send and receive data 1. An apparatus for testing computer systems corn- 
correctly. This test gives pass or fail only. prising: 

„_,_. _ r< _ a. a base unit, the base unit comprising a central pro- 

SCSI Test (SCSI) cesstng unit for executing instructions, issuing com- 

This test verifies that the SCSI (small computer sys- 65 mauds, and receiving data from a first computer 
tern interface) chip functions in all modes and that the system; 

SCSI bus can send and receive data correctly. This test b. a first connecting module which contains at least 
gives pass or fail only. one connector for coupling to the first computer 
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system, said connector being coupled to an existing 
connector on the first computer system, said first 
connecting module being interchangeable with a 
second module for interfacing with a second com- 
puter system, said at least one connector compris- 5 
ing a disk drive connector, and 
c. a first nonvolatile memory module coupled to the 
base unit, the first nonvolatile memory module 
comprising a first set of tests for the first computer 
system, the first nonvolatile memory module being 10 
interchangeable with a second nonvolatile memory 
module comprising a second set of tests for a sec- 
ond computer system, said first set of tests includ- 
ing an initialization circuit causing said first com- 
puter system to initially attempt to execute an inter- 15 
nally-stored set of diagnostic routines, and if said 
initialization circuit is unsuccessful at causing said 
first computer system to attempt to execute said 
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internally-stored set of diagnostic routines, then 
said initialization circuit causing said apparatus to 
emulate a disk drive through said disk drive con- 
nector and causing said first computer system to 
perform a bootstrap initialization of said first com- 
puter system from said apparatus by loading a set of 
externally-stored diagnostic routines from said first 
nonvolatile memory module. 

2. The apparatus of claim 1 wherein the base unit 
comprises a keyboard for entering commands and a 
display for displaying information to a user. 

3. The apparatus of claim 1 wherein the base unit 
comprises a connector which may be coupled to a third 
computer system which remotely controls the base unit 
and issues commands through the base unit to the first 
computer system. 

« » * * • 
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